Dialogue processing method and device based on historical session recognition, equipment and medium

Abstract

The invention relates to the technical field of semantic analysis, can be applied to business scenes of financial science and technology, medical health and the like, and discloses a dialogue processing method, device, equipment and medium based on historical dialogue recognition, which comprises the following steps: receiving an interaction request, judging whether a stored historical dialogue identifier is associated, directly generating first response data when the stored historical dialogue identifier is not associated, and sending the first response data to a server; and extracting historical session data from the database when the data are associated, stopping extraction after a capacity threshold value is reached, integrating the interaction request and the extracted data into context parameters, submitting the context parameters to the intelligent processing module to obtain second response data, and outputting the first response data or the second response data. According to the method, on the basis of judging the session relevance, the historical session data is subjected to limited extraction, and the context parameters are constructed, so that the capability of keeping session continuity under the condition that computing resources are limited is realized, and the processing efficiency of multiple rounds of sessions and the system expandability are improved.

Description

Technical Field

[0001] The present invention relates to the field of semantic parsing technology, and in particular to a conversation processing method, apparatus, device and storage medium based on historical conversation recognition. Background Art

[0002] Existing conversational systems widely utilize natural language processing technologies based on pre-trained language models to support multi-round interactions between users and the system. However, in practical applications, especially in large-scale concurrent or resource-constrained environments, the computational load of the algorithm model becomes a key factor limiting system response efficiency and conversation continuity. To reduce the pressure on algorithm services, existing systems often do not retain complete conversation history information on the algorithm model side, instead relying on external modules or simplified strategies to manage conversation input. Due to the lack of an independent conversation management mechanism, the system struggles to effectively maintain the coherence and integrity of contextual information throughout multi-round conversations.

[0003] In FinTech scenarios such as online financial consulting, loan review assistance, and compliance Q&A, users often need to repeatedly state their needs, provide additional information, or clarify details through multiple rounds of conversation. Existing systems, unable to track and integrate historical interactions, lack continuity and consistency in responses, and can even result in irrelevant answers and repeated inquiries. This negatively impacts user experience and the accuracy of business decisions.

[0004] In healthcare applications such as remote consultations, personalized health advice, and chronic disease follow-up, conversations between users and systems are often highly continuous and context-dependent. Currently, most systems only consider the current input in each round of conversation, ignoring important diagnostic and treatment clues, historical symptom descriptions, and other information provided in previous interactions, which affects the complete understanding of the condition. Furthermore, when processing longer conversations, the system often faces the problem of over-limited model input. Simple truncation strategies can easily lead to the omission of key content, thereby reducing the accuracy and reliability of diagnostic and treatment assistance recommendations.

[0005] Furthermore, to improve model responsiveness, existing systems lack the ability to fine-tune historical conversation content. They cannot dynamically filter or summarize historical data based on dimensions such as length, semantic redundancy, or importance, making it difficult to control resource consumption while ensuring semantic coherence. Therefore, building a conversation management mechanism capable of context management, input length control, and multi-turn dialogue support within the constraints of algorithmic model resources has become a major technical challenge facing current intelligent dialogue systems. Summary of the Invention

[0006] The main purpose of the present invention is to provide a conversation processing method, device, equipment and storage medium based on historical conversation recognition, aiming to solve the technical problem that the existing technology lacks a mechanism that can effectively extract and organize the context of multiple rounds of conversations while ensuring response efficiency in scenarios with limited algorithm resources, resulting in difficulty in achieving coherent and resource-controllable multi-round conversation processing.

[0007] To achieve the above objectives, the present invention provides a conversation processing method based on historical conversation recognition, comprising:

[0008] receiving an interaction request, and determining whether the interaction request is associated with a stored historical session identifier;

[0009] If the interaction request is not associated with a stored historical session identifier, sending the interaction request to an intelligent processing module to generate first response data;

[0010] If the interaction request is associated with a stored historical session identifier, extracting historical session data associated with the historical session identifier from the database in the order of creation time of the historical sessions, and terminating the extraction operation when the total number of bytes of the extracted historical session data reaches a preset capacity threshold;

[0011] Integrating the interaction request with the extracted historical session data into context parameters;

[0012] Submitting the context parameters to the intelligent processing module and receiving second response data returned by the intelligent processing module;

[0013] The first response data or the second response data is output.

[0014] Furthermore, to achieve the above-mentioned purpose, the present invention provides a conversation processing device based on historical conversation recognition, comprising:

[0015] A session identification module, configured to receive an interaction request and determine whether the interaction request is associated with a stored historical session identifier;

[0016] a response generating module, configured to send the interaction request to the intelligent processing module to generate first response data if the interaction request is not associated with a stored historical session identifier;

[0017] a historical data extraction module configured to extract, if the interaction request is associated with a stored historical session identifier, historical session data associated with the historical session identifier from a database in chronological order of creation of the historical sessions, and terminate the extraction operation when the total number of bytes of the extracted historical session data reaches a preset capacity threshold;

[0018] a context building module, configured to integrate the interaction request and the extracted historical session data into context parameters;

[0019] a context response module, configured to submit the context parameters to the intelligent processing module and receive second response data returned by the intelligent processing module;

[0020] The result output module is configured to output the first response data or the second response data.

[0021] Furthermore, to achieve the above-mentioned purpose, the present invention also provides a computer device, which includes a memory, a processor, and a conversation processing program based on historical conversation recognition stored in the memory and executable on the processor, wherein the conversation processing program based on historical conversation recognition, when executed by the processor, implements the steps of the conversation processing method based on historical conversation recognition as described above.

[0022] Furthermore, to achieve the above-mentioned purpose, the present invention also provides a computer-readable storage medium, on which a conversation processing program based on historical conversation recognition is stored. When the conversation processing program based on historical conversation recognition is executed by a processor, the steps of the conversation processing method based on historical conversation recognition as described above are implemented.

[0023] Beneficial effects: The present invention relates to the field of semantic parsing technology and can be applied to business scenarios such as financial technology and medical health. It discloses a conversation processing method based on historical conversation recognition, including: receiving an interaction request, determining whether to associate with a stored historical conversation identifier, directly generating first response data if not associated, extracting historical conversation data from a database if associated, terminating the extraction after reaching a capacity threshold, integrating the interaction request and the extracted data into context parameters, submitting them to an intelligent processing module to obtain second response data, and outputting the first response data or the second response data. The present invention achieves the ability to maintain conversation coherence under limited computing resources by performing limited extraction of historical conversation data and constructing context parameters based on the judgment of conversation relevance, thereby improving the processing efficiency of multi-round conversations and the scalability of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] The present invention will be further described below with reference to the accompanying drawings and embodiments, in which:

[0025] Figure 1 A schematic diagram of an application environment of a conversation processing method based on historical conversation recognition in an embodiment of the present invention;

[0026] Figure 2 This is a flow chart of an embodiment of a method for processing conversations based on historical conversation recognition according to the present invention;

[0027] Figure 3 This is a functional module diagram of a preferred embodiment of a conversation processing device based on historical conversation recognition according to the present invention;

[0028] Figure 4 A schematic diagram of the structure of a computer device according to an embodiment of the present invention;

[0029] Figure 5 FIG. 2 is another structural diagram of a computer device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0030] It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0031] The dialogue processing method based on historical conversation recognition provided by the embodiment of the present invention can be applied in the following situations: Figure 1 In an application environment, the user terminal communicates with the server terminal through a network. The server terminal can receive an interaction request through the user terminal, determine whether to associate with a stored historical session identifier, directly generate first response data if not associated, extract historical session data from the database if associated, terminate the extraction after reaching a capacity threshold, integrate the interaction request and the extracted data into context parameters, submit them to the intelligent processing module to obtain second response data, and output the first response data or the second response data. The present invention achieves the ability to maintain conversation continuity under limited computing resources by performing limited extraction of historical session data and constructing context parameters based on the judgment of conversation relevance, thereby improving the processing efficiency of multi-round conversations and the scalability of the system. The user terminal can be, but is not limited to, various personal computers, laptops, smart phones, tablet computers and portable wearable devices. The server terminal can be implemented with an independent server or a server cluster consisting of multiple servers. The present invention is described in detail below through specific embodiments.

[0032] See also Figure 2 , Figure 2 This is a flow chart of an embodiment of a method for processing a conversation based on historical conversation recognition provided by the present invention. It should be noted that although a logical order is shown in the flow chart, in some cases, the steps shown or described may be performed in a different order than that shown here.

[0033] like Figure 2 As shown, the conversation processing method based on historical conversation recognition proposed by the present invention includes the following steps:

[0034] S10, receiving an interaction request, and determining whether the interaction request is associated with a stored historical session identifier;

[0035] In this embodiment, receiving an interaction request is the starting point of the entire human-computer dialogue process. This interaction request typically takes the form of natural language text or voice commands entered by the user on the terminal, which must be accessed and processed in real time. This text content is transmitted to the backend server interface via the client or front-end system, triggering the dialogue processing flow. This access can be achieved through HTTP requests, WebSocket connections, or API gateway access, ensuring that the diverse user input is uniformly encapsulated and stably transmitted within the technical architecture.

[0036] Parsing the content of the interaction request requires relying on a natural language understanding model, which may be based on a large language model, a classifier, or a multimodal understanding structure, and performs word segmentation, syntactic analysis, entity recognition, and intent recognition tasks on the input content. The core intent label is a set of labels derived from semantic classification, which is used to represent the semantic goal of the user's request in this round. Its generation process can refer to the output of the intent recognition model, such as a BERT-based classifier or an intent branch model in a multi-task learning architecture. The key entity set refers to objects or concepts in the request that are closely related to the interaction topic, such as entities such as "medical insurance settlement", "financial management account", and "diabetes management". They are usually identified by a named entity recognition model and classified by type, which may include equipment, drugs, departments, financial products, time intervals, etc.

[0037] Determining whether to associate stored historical conversation identifiers is crucial for determining whether the historical context is reusable. The key lies in establishing a semantic association mapping mechanism. In existing multi-round conversations, each segment of historical conversation data is accompanied by semantic metadata, including historical core intent labels and historical key entity sets. This information is constructed and archived in a structured mapping table when the data is written. This table can be an index table in a relational database or a vector database storing embedding representations. When making this determination, the semantic features in the current interaction request must be compared with those in the historical data.

[0038] Comparison can be implemented based on semantic similarity calculations and entity intersection matching. Similarity between intent labels can be measured using a vector space model, such as calculating the cosine similarity between the label embedding vectors. Overlap determination of key entities can be achieved through set operations, keyword hash indexing, or synonym extension matching. A valid judgment requires that the current request has significant similarity with any historical record at the intent or entity level, with the significance threshold controlled by a pre-set threshold.

[0039] The result of the association check is used to guide the decision about whether to proceed with the session renewal process, so this check must be accurate and low-latency. This is typically achieved through online comparison to avoid delayed data loading. To ensure the integrity of the semantic comparison, the system must set status and expiration fields to ensure that matches are only performed against valid, unexpired historical records.

[0040] Based on pre-trained language models as the foundational framework for intent and entity recognition, user interaction request text can be parsed and converted into structured semantic features. At the deployment level, this can be done by invoking existing NLP services or embedding a model inference engine within backend services for local processing. To enhance the diversity of semantic judgments, semantic extension mechanisms can be introduced, such as synonymous tag tables for intent labels and industry ontology mappings for entities, to build broader association matching rules.

[0041] In practical applications, you can choose to use vector search engines such as Elasticsearch and Milvus to build a historical semantic feature library, encode historical intents and entities into vectors, and quickly retrieve the most similar session identifiers; you can also use traditional relational databases to design multi-field joint indexes to filter core intent tags and key entity fields.

[0042] For the validity judgment part, you can design an expiration judgment rule, for example, use the timestamp to determine whether it exceeds the usage window of 7 days, 30 days, etc.; you can also combine the user status field, such as "session closed" and "user logged out" to filter non-reusable historical records.

[0043] Example: In healthcare, when patients repeatedly ask about medications for a certain chronic disease, such as insulin adjustments for diabetes, the system can extract semantic tags and drug entities such as "diabetes management" and "insulin injection" to establish semantic associations with historically saved diabetes medication conversations, thereby retrieving historical questions and answers for contextual continuation and improving the quality of continuous conversations.

[0044] In the financial field, when users initiate multiple requests for "pension planning" or "risk assessment adjustment" at different time points, the system can automatically determine whether the current request has a contextual connection with a previously existing conversation through key intentions or words such as "risk assessment" and "fund redemption", avoiding repeated explanations and inquiries, and improving service experience and work efficiency.

[0045] By extracting semantic features from interaction requests and comparing them with those from historical session identifiers, we can accurately determine conversation relevance even under resource-constrained conditions, enabling the system to conditionally enter a multi-round dialogue process. Introducing semantic judgment and entity intersection recognition mechanisms during the judgment phase improves the accuracy of context reuse, avoiding misjudgments of context paths in resource-constrained environments, which can lead to response errors or redundant computations, thereby improving the overall dialogue system's response stability and resource utilization efficiency.

[0046] S20, if the interaction request is not associated with a stored historical session identifier, sending the interaction request to an intelligent processing module to generate first response data;

[0047] In this embodiment, when a user submits an interaction request, the system first identifies the request's data structure, extracting the user's natural language input and any additional contextual metadata (e.g., user ID, device information, and timestamp). The system then determines whether the request carries a historical session identifier. If not, or if the identifier does not match any valid historical session record in the database, the interaction request is identified as a new session request.

[0048] Without a historical session identifier, the system skips the steps of extracting historical data and constructing context parameters and directly forwards the user interaction request to the intelligent processing module. This forwarding operation is completed through the internal service routing mechanism. The request content is encapsulated in a standard input format, such as JSON structure or gRPC protocol transmission, and contains natural language text and optional business tag fields.

[0049] After receiving a request, the intelligent processing module encodes the text content, performs semantic modeling, and generates language. Since there is no historical data input, the module processes only the current request text and generates the initial response data. The response content is returned to the requester in a structured format for subsequent output or storage.

[0050] The process of request incoming, judgment, dispatch, and response is an atomic process executed sequentially. Judgment results without historical session identifiers control process branches, determining whether to perform context building and historical retrieval, ensuring the uniqueness and clarity of the data flow path.

[0051] The entire operation process relies on the key condition of "whether the historical session identifier matches", the execution action is "sending the request directly to the intelligent processing module", and the result is "generating the first response data". This response data will be bound to the original request and used for recording and output in subsequent processing flows.

[0052] In an actual deployment environment, if the request submitted by the user does not contain a valid historical session identifier, the server will immediately parse the user input content from the message body after receiving the request, and encapsulate the content together with the request metadata into a request data structure. This structure includes but is not limited to the request text, user identifier, request source, timestamp, etc. The data structure is sent to the intelligent processing module through the service internal interface or the model middle-end system. The intelligent processing module can be an inference service that integrates a large language model, or it can be an externally deployed API service. In order to maintain universality, the module receives input requests in a standard format, performs word segmentation, semantic modeling, encoding processing and other operations, and generates a response result. The response result can be a natural language reply based on a language generation model, a matching output based on a rule engine, or a combined response of a hybrid model.

[0053] In the specific implementation, if the system is deployed under a microservice architecture, the intelligent processing module can be called through RPC (such as gRPC) to achieve low-latency request transmission and response convergence. You can also use an asynchronous message queue to push the request to the inference task queue, and the model service will pull it asynchronously for execution, which is suitable for scenarios with tight resources for large models. After the response is generated, the result is returned in a standard output format and passed back to the main processing flow for output or storage. In order to ensure transmission efficiency and response consistency, a request parameter compression mechanism can be introduced before sending the request, and an idempotence verification module can be added to the request-response link to avoid repeated calls or response conflicts. The entire process design does not rely on historical context information and is suitable for stateless conversation scenarios such as the first round of dialogue, static question answers, and real-time inquiries.

[0054] Example: In a healthcare business scenario, a user asks the question "Do I need a CT scan because I've been feeling dizzy lately?" for the first time through the health consultation system. Because the request does not carry a historical session identifier, the system identifies it as an initial conversation and transmits the question directly to the intelligent processing module supported by the medical knowledge base. This module generates professional advice for the question without loading historical symptom descriptions or previous question and answer information, thus reducing response time.

[0055] In a financial business scenario, if a user first asks, "How long can I defer my credit card bill?" Since there's no previous interaction, the request goes directly to the intelligent response module, which generates an initial response based on credit card business rules, such as "Currently, the maximum extension is 30 days." This process doesn't rely on contextual information, is suitable for non-persistent problem scenarios, and improves service accessibility.

[0056] In common scenarios like intelligent customer service or question-answering bots, when a user asks "What can you do?", due to the lack of conversational context, the system sends the request to the model service to generate a general description of capabilities, eliminating the need for historical analysis and enabling a quick response. By skipping the context loading process, response efficiency in new conversation scenarios can be significantly improved.

[0057] When an interaction request is detected as not associated with any valid historical session identifier, it is directly submitted to the intelligent processing module to generate response data, skipping the historical data loading and context building process. This path switching mechanism effectively reduces request latency, conserves model context input length, and improves processing efficiency. It also avoids redundant data retrieval in scenarios where no historical information is available, reducing the load on system resources. In scenarios where intelligent processing module resources are limited, this method ensures service response speed through path simplification and improves the stability and scalability of the multi-turn dialogue management system.

[0058] S30, if the interaction request is associated with a stored historical session identifier, extracting historical session data associated with the historical session identifier from the database in chronological order of the historical sessions, and terminating the extraction operation when the total number of bytes of the extracted historical session data reaches a preset capacity threshold;

[0059] In this embodiment, after determining that the current interaction request is associated with a historical session identifier, the historical session data corresponding to the historical session identifier is extracted from the database. The historical session identifier can be generated by combining the user identifier and context tags, or it can be persistently recorded by the front-end application in historical rounds and transmitted along with the interaction request. The historical session data in the database is typically stored as the smallest record unit for each question-and-answer pair, including fields such as the request text, response text, role identifier, and timestamp.

[0060] Extraction operations are sorted by creation time. The creation time field can be derived from the automatically generated timestamp in the database record or the session record time generated by the application logic. The creation time field is sorted in ascending order, ensuring that the data is loaded sequentially from the earliest to the latest session round. This sequential design facilitates the subsequent construction of a semantically coherent context window and avoids logical gaps in historical records.

[0061] During data extraction, the total number of bytes of historical session data extracted must be continuously calculated. This cumulative calculation can be based on the sum of the response and request data for each record, or it can include the storage cost of metadata fields. The total byte count can be evaluated using the total number of bytes encoded in UTF-8 to more accurately control model input length or system memory load. This total number of bytes is compared in real time against a preset capacity threshold set by the system. If the cumulative value reaches or exceeds this threshold, the extraction of subsequent records is terminated immediately to avoid data overflow and subsequent context splicing failures.

[0062] In practice, this can be achieved through a combination of paging reads and streaming accumulation. Paging reads avoid the memory pressure caused by loading all data at once, while streaming accumulation dynamically determines whether to terminate the extraction process early. If the extraction threshold has not been reached, the next later historical record is extracted until the threshold is exceeded or there are no more records.

[0063] During service deployment, the creation time field can be sorted using a timestamp field generated by the database layer (such as the created_at field in MySQL). During data extraction, query logic can be dynamically constructed using the ORM framework or SQL statements, for example, querying historical Q&A records in ascending order by the created_at field. To control the size of transmitted data, each read operation can be limited to a certain number of records and byte counts can be calculated. A common method involves calling len(data.encode("utf-8")) within the program to estimate the byte length. The capacity threshold can be set based on the input length limit of the downstream model. For example, for a model with a context limit of 4K tokens, the capacity threshold can be set to an appropriate byte-converted value (such as 12KB-16KB) to prevent overflow. In multi-session merging scenarios, multiple session identifiers can be used to concurrently extract corresponding records and then merge and sort them, but the merge and sorting is always performed based on the unified creation time field. To improve data extraction efficiency, an index structure can be established for the created_at field in the database to increase sequential scan speed.

[0064] Example: In a healthcare scenario, when a user asks three consecutive questions about diabetes medication through a chronic disease management assistant, the system identifies them as a single conversation using the session identifier. Before generating a new response, the server extracts the data from the previous three rounds of questions and responses in chronological order and controls the byte length within the model's acceptable range, ensuring that the large model can provide professional advice based on the complete consultation history.

[0065] In the financial sector, users inquire about loan terms and conditions, repeatedly asking about interest rate changes and prepayment rules. The session management service identifies the associated session identifier and extracts the relevant session history from the database. The extraction process terminates when the total data reaches the upper limit of 8KB, retaining only the first few rounds of conversation that are most informative for the current round of questions. This prevents model input overload and affects semantic coherence. This mechanism improves response accuracy and reduces the use of inference computing resources.

[0066] By limiting the extraction order to creation time, from earliest to latest, and introducing a byte limit control mechanism during the extraction process, we achieve orderly organization and dynamic pruning of multi-round conversation history context. This ensures the temporal continuity of contextual semantics while effectively mitigating the risk of truncation or errors caused by exceeding the context length limit during inference on large models. By using a simultaneous extraction and statistics approach, we also maximize the use of the available context window, improving model response quality and controlling service resource consumption.

[0067] S40, integrating the interaction request and the extracted historical session data into context parameters;

[0068] In this embodiment, the integration of the current interaction request and the extracted historical conversation data is used to construct the context parameters required for large language model processing, which must follow the four basic logics of semantic continuity, clear role distinction, consistent format, and input compatibility. The structure of the interaction request usually contains field information such as the request text, role identifier, and timestamp field, while the historical conversation data should also consist of question and answer records arranged in chronological order. The integration operation is not just about merging the two data sets, but also requires uniform encoding and organization of the data according to a specific order, rules, and structural format, ultimately forming an input format acceptable to the model.

[0069] During implementation, the extracted historical conversation data must first be cleaned and preprocessed to ensure that each question-and-answer record is complete and contains the requester and responder role identifiers, typically represented by "user" and "assistant," or their locale-specific equivalents. If the historical records contain unlabeled or mixed-up role records, the role information must be automatically completed based on the request and response fields.

[0070] Next, all historical session data is sorted in descending order by creation time to construct a historical data sequence. The current interaction request is considered a continuation of this historical sequence, so the interaction request content is appended to the end of the sequence, along with the requester role identifier.

[0071] To enhance the language model's understanding of the current context, a concise contextual topic description sentence can be added to the beginning of the historical data sequence. This sentence can be generated by the system from historical keywords, entity words or previous summaries, aiming to provide semantic target normalization clues across rounds.

[0072] The integrated data needs to be encoded into a model-compatible input data format. Common formats include OpenAI ChatML, HuggingFace, or platform-defined structured formats. The encoding process not only requires conversion to a unified markup language format but also requires length evaluation and truncation to avoid inference failures due to excessively long context.

[0073] For example, during the text structure processing phase, a structured data template can be constructed to format each historical record into the "[role] content" format, such as "[user] How do I apply for a loan?" and "[assistant] Please log in to the platform and click the loan application button..." During integration, all historical questions and answers are sequentially concatenated with the current request into a single text stream. This concatenation process supports compatibility strategies for different formats. For example, if the model supports multi-segment dialogue sequences, each segment can be encapsulated in a separate JSON object. If the model only supports continuous text input, line breaks or delimiters are inserted to distinguish between turns.

[0074] Contextual topic description sentences can be generated using keyword extraction. For example, keyword frequency statistics are performed on the past 10 rounds of questions and answers, and the most frequent intent tags are extracted. These are then combined with user names or industry backgrounds to form sentence structures, such as "The current conversation involves questions and answers about financial product terms" or "The topic of this conversation is recommendations for cancer diagnosis and treatment plans."

[0075] During the input encoding phase, developers can call the pre-encoder (such as tokenizer) provided by the language model platform to convert the text sequence into a token sequence accepted by the model and evaluate the total length of the tokens. If the total length exceeds the limit, the earliest historical round is truncated based on the context importance strategy.

[0076] Example: In a healthcare scenario, a user repeatedly inquires about hypertension medication compatibility on a chronic disease management platform. The system extracts the user's questions, doctor's advice, and test data from the previous three rounds of Q&A as historical session data. After role annotation and chronological sorting, it merges this data with the current query to generate context parameters. When the interaction request is integrated into the end of the context, the contextual topic prompt "The patient is seeking long-term blood pressure management consultation" is added, allowing the model to accurately identify the semantic direction.

[0077] In financial services, corporate customers continuously ask questions about the policy cancellation process. When constructing the context, the system extracts fields such as "product type" and "cancellation reason" from historical interactions into suggestive subject information, and splices it with the current question "How long is the refund cycle?" to form an enhanced context. Through structured processing, the model's understanding consistency is enhanced to avoid the model mistakenly treating new questions as the first inquiry.

[0078] By constructing context parameters that include historical semantic chains, the language model can reason based on the current interaction request and multiple rounds of semantic clues in the historical context, improving the accuracy and coherence of the response content. The construction of context parameters achieves structural standardization while retaining key semantic information, making the input consistency and controllability of the subsequent model reasoning stage stronger, adapting to different model input structures and improving model processing efficiency. Through role identification and time sorting, semantic coherence and clear dialogue structure are ensured, supporting question reconstruction and knowledge derivation in complex multi-round scenarios.

[0079] S50, submitting the context parameters to the intelligent processing module and receiving second response data returned by the intelligent processing module;

[0080] In this embodiment, submitting the context parameters to the intelligent processing module and receiving the second response data returned by it is the core operation to complete the context-based question and answer generation. The intelligent processing module generally refers to a large language model with language modeling, context perception and semantic generation capabilities, and its deployment form can be a local reasoning service, a remote API interface or a proprietary model engine. The context parameters have been encoded into a structured model input format in the previous stage. The input must comply with the token format, maximum length constraint and role structure requirements supported by the model.

[0081] The submission process involves selecting an interface call and a data transmission mechanism. Context parameters are typically transmitted as payload to the model inference service interface endpoint via HTTP requests, gRPC, or intranet RPC calls. The call typically involves four steps: encapsulating the input request, transmitting, asynchronously waiting, and receiving the result.

[0082] Receiving the second response data returned by the model requires compatible decoding capabilities. The format of the model's return results may vary depending on the deployment platform, but common formats include fields such as "response," "answer," and "choices" in JSON format. When parsing the model's return value, the system should extract the final text output and format it for subsequent output or storage operations.

[0083] In some scenarios, the intelligent processing module may also provide additional auxiliary information, such as the number of response tokens, probability distribution, reference source, multiple rounds of candidate generation, etc. These additional fields can be used for quality assessment, candidate reordering, or further compression of transmission content.

[0084] To improve processing stability, a retry mechanism for failed calls can be added, with parameters such as the maximum number of retries and the timeout for retrying. If model processing fails, a degraded response should be generated or an error prompt should be returned.

[0085] In practice, an asynchronous HTTP client encapsulates context parameters as a POST request and sends it to the intelligent processing module's service address. Example fields include the input token sequence, the current request ID, the model name, and parameter configuration. Upon receiving the response, the system first extracts the result fields, then standardizes the format, and outputs the final text as the system's second response data.

[0086] In high-concurrency scenarios, batch inference or parallel task distribution mechanisms can be introduced to submit multiple context parameters in batches according to resource allocation rules, reducing model initialization and switching overhead and improving throughput efficiency.

[0087] If the model output is stream content, you can use a fragmented reception and splicing approach to generate user-visualized content in real time. For example, you can maintain a connection via WebSocket and immediately send each received response to the user interface, creating a word-by-word generation experience.

[0088] By submitting complete context parameters to the intelligent processing module, the model can perform precise reasoning based on historical semantic links and the current request content, thereby generating semantically complete and contextually continuous second response data. This mechanism significantly improves the question-answering system's adaptability to multi-round dialogue scenarios, especially in tasks such as medical consultations and financial consulting that require understanding based on accumulated prior information. It prevents the model from ignoring historical clues or misjudging current intent. In addition, through standardized interface submission and result parsing, the system has good module decoupling and model replacement capabilities, facilitating model upgrades or cross-platform deployment.

[0089] S60: Output the first response data or the second response data.

[0090] In this embodiment, the system determines the output object based on the processing path of the current interactive request. If no historical session identifier is associated, the system directly outputs the first response data generated by the intelligent processing module. If the historical session identifier is associated and the context parameters are constructed, the system outputs the second response data. The system writes the response data content to the output buffer or output stream in a standard format and calls an interface service to transmit the content to the front-end interactive interface.

[0091] Once the response data is generated, the system triggers the data output process, which begins with a check of the integrity of the response data structure. The response data must include fields such as the response text, generation time, and unique interaction identifier. Missing any core fields will terminate the response output and trigger error logging and exception callback mechanisms.

[0092] After passing structure validation, the system enters the field conversion phase. Some internally generated fields may not conform to the user interface display protocol, necessitating unified mapping relationships. For example, if the model returns a field named "answer_text" but the user interface requires "content," the system will automatically perform field key name conversion to ensure that downstream display components can accurately parse the response content. These mapping relationships are driven by pre-configured format configuration files and are adjustable and dynamically updateable.

[0093] After field formatting, the system performs compliance filtering on the response text. This filtering mechanism scans the text word by word based on a sensitive word identification policy library. Upon finding a keyword, the system selects desensitization, generalization, or blocking prompts based on the matching strategy. The filtering policy library supports multi-level rule priority definitions. For example, in medical scenarios, personal medical information is prioritized, while in financial scenarios, account or transaction identifiers are prioritized. Dynamic updates to the policy library are possible without restarting the service.

[0094] The filtered response text is repackaged into a unified data format, with header identifiers and security verification fields added, ready for push to the user interface. The system also adds optional status fields during the packaging phase, such as "Anonymous Status Marker" and "Generated Source Identifier," to help the front-end determine whether to display a prompt.

[0095] Data push utilizes two channels: a real-time push channel and a backup asynchronous write channel. The former pushes encapsulated response data to the target user interface via WebSocket, HTTP persistent connections, or in-app event channels. The latter is used to write to logging systems, audit systems, or model feedback training modules, ensuring traceability and tracing of response data.

[0096] After data successfully reaches the user interface and is confirmed by the receiving end, the system writes back the response output status and triggers subsequent interaction processes, such as dialogue state persistence and session ID renewal, to ensure the continuity of multiple rounds of dialogue. If reception fails or times out, the system enters a retry channel. After the maximum number of attempts is exceeded, the degradation path is recorded and a warning signal is issued.

[0097] In actual deployment, the system can configure different output strategies based on business scenarios. For example, in the healthcare sector, the generated response data often contains highly sensitive content, such as sensitive physiological indicators, medication names, and medical history descriptions. Using a pre-set medical compliance rule table, the system can encrypt or generalize entity fields appearing in the response text. For example, replacing "amoxicillin" with "broad-spectrum antibiotics" or "diabetes diagnosed in January 2023" with "previously diagnosed with chronic metabolic diseases" can be replaced. This rule table is driven by a medical knowledge base and can be adjusted as regulatory policies change.

[0098] In financial services, the response data output stage must additionally meet transaction compliance and risk control requirements. For example, when processing a customer inquiry regarding account risk alerts, if the response includes information such as asset type, balance estimate, or transaction behavior, the system will first load the sensitive field template and desensitization policy. Then, based on the customer's role level and permissions, it will dynamically determine whether the field should be displayed or masked with a "***" (a special character). When data is output, it will be accompanied by field-level access control tags, allowing the front-end interface to determine whether to mask the display.

[0099] In resource-constrained deployments, the response data output process can be configured in "lightweight mode." This bypasses structural reorganization and some non-core compliance checks, directly encoding and encapsulating the model response content and pushing it to the client. This mode is suitable for internal training environments or partially localized deployments with low latency requirements. The system will mark such response data as "informal response" to prevent it from entering long-term conversation chains.

[0100] To improve system stability, some mobile applications support preloading and pre-pushing of output data. When the model generates response data, the system first writes the data to the local cache pool and immediately triggers a loading animation or placeholder text display. Once the data content is processed by the main thread, it is automatically replaced, improving the perceived response speed.

[0101] Furthermore, the response output module supports multi-channel distribution. In addition to regular UI push, response copies can be configured to be written simultaneously to the model training reflow channel, logging channel, and behavior audit channel, implementing a closed-loop "generate-and-feedback" training architecture. Different channels have independent data identification headers and transmission protocols, facilitating subsequent asynchronous debugging, model improvement, and compliance reviews.

[0102] In multilingual interaction scenarios, the language adaptation engine can be configured during the response output phase based on user language preferences. If the interaction request language is English, the system automatically performs translation and re-encoding on the Chinese model output to ensure language consistency and contextual coherence. It supports UTF-8 encoding standards and preserves format structure information, facilitating seamless switching and interface integration for bilingual business processes.

[0103] By determining whether an interaction request has a historical contextual basis and accurately selecting the output of the first or second response data based on this determination, the system ensures that it responds appropriately to both initial and subsequent questions, thereby improving the consistency and response quality of multiple rounds of conversation. This mechanism avoids the redundancy caused by loading irrelevant historical information in context-free scenarios and ensures that model output remains consistent with historical semantics throughout multiple rounds of conversation. The precise output of the final response provides users with a clearer and more accurate interaction experience while also reducing the waste of model computing resources.

[0104] The present invention relates to the field of semantic parsing technology and can be applied to business scenarios such as financial technology and healthcare. A method for processing conversations based on historical conversation recognition is disclosed, comprising: receiving an interaction request, determining whether to associate with a stored historical conversation identifier, directly generating first response data if no association is found, extracting historical conversation data from a database if an association is found, terminating the extraction after reaching a capacity threshold, integrating the interaction request and the extracted data into context parameters, submitting the data to an intelligent processing module to obtain second response data, and outputting either the first response data or the second response data. By performing limited extraction of historical conversation data and constructing context parameters based on determining conversation relevance, the present invention achieves the ability to maintain conversation coherence under limited computing resources, thereby improving the processing efficiency and system scalability of multi-round conversations.

[0105] In one embodiment, the above step S10 includes:

[0106] S101, receiving an interaction request, performing natural language parsing on the text content of the interaction request, and extracting the core intent tag and key entity set of the interaction request from the text content of the interaction request;

[0107] S102, comparing the core intent label and key entity set with a session semantic association mapping table in a database, wherein the session semantic association mapping table stores a historical core intent label and a historical key entity set corresponding to each historical session identifier;

[0108] S103: If the core intent tag of the interaction request is consistent with or semantically similar to a historical core intent tag of a historical session identifier in the session semantic association mapping table, or if the key entity set of the interaction request overlaps with a historical key entity set of a historical session identifier, then mark the historical session identifier as a candidate association session identifier;

[0109] S104, screening out historical session identifiers that are valid and not expired from the candidate associated session identifiers;

[0110] S105: If at least one valid and unexpired historical session identifier is screened out, it is determined that the interaction request is associated with the stored historical session identifier; otherwise, it is determined that the interaction request is not associated with a valid historical session identifier.

[0111] In this embodiment, after the system receives the interaction request sent by the user, it is necessary to immediately perform language analysis on its content in order to identify the semantic subject and associated context of the request. This processing process starts with the text parsing module, and uses the natural language parsing model to perform structural analysis on the sentences in the interaction request to extract a set of keywords that can express the core demands of the user. The keyword set mainly includes two types of data structures. One type is the core intent label used to characterize the user's interaction goals, such as "account risk" and "drug use recommendations"; the other type is a set of key entities with specific references, such as "financial product A" and "insulin injection". The core intent label and the key entity set together constitute the semantic vector basis for subsequent comparison and retrieval.

[0112] Retrieving semantic association information from the database does not directly retrieve historical session data. Instead, it first reads the session semantic association mapping table. This mapping table is a pre-built structured search index. Each index entry is associated with a historical session identifier and stores the semantic tags and entity sets processed in that session. This pre-defined semantic structure allows the system to determine the relationship between interaction requests and historical sessions based on semantic proximity, rather than relying on exact keyword matching.

[0113] During the comparison process, a semantic vector encoding method is first used to calculate the cosine similarity between the intent label vector of the current request and the intent label vector of the historical session. If the similarity exceeds a preset threshold, the semantics are determined to be similar. For matching key entity sets, a set intersection method is used. If at least one element in the two sets overlaps, semantic overlap is considered. If either the semantic similarity of the intent label or the overlap of the key entity sets is met, the system adds the corresponding historical session identifier to the candidate association set.

[0114] To ensure accurate results, the historical session identifiers in the candidate association set must undergo further validity verification. This verification relies on two attribute fields: the status field, which indicates whether the historical session has been terminated by the user, a system interruption, or marked as invalid; and the expiration time field, which controls whether the session lifecycle is still within the permitted range. Only when both fields meet the preset conditions is the historical session considered valid.

[0115] If at least one session identifier in the candidate set meets the aforementioned validity requirements, the current interaction request is considered associated with a previous session. Otherwise, it is considered a new request and a new session process is initiated. The entire decision process supports multi-threaded parallel judgment, vectorized acceleration, and cache comparison mechanisms to ensure uncompromised responsiveness in high-concurrency scenarios.

[0116] During actual system deployment, the extraction of core intent labels can be achieved using different language models. For example, for general scenarios, pre-trained BERT or RoBERTa models can be used for sentence vector encoding. For vertical business areas such as healthcare or finance, FinBERT, BioBERT, and other field models can be used to optimize intent recognition accuracy. The identification of key entity sets is usually achieved in conjunction with a Neural Entity Recognition (NER) model, which is trained on annotated corpus to recognize domain-specific terms such as names of people, drugs, and projects.

[0117] The generation of the session semantic association mapping table is typically performed simultaneously with the writing of historical user session data back to the database. The system extracts the topic tags and entities involved in each session and writes them in a structured form into a separate table. This table is then quickly loaded and compared using an index before processing new requests. Semantic similarity calculations rely on built-in vector computation libraries, such as Faiss or Annoy, which support vector compression and fast approximate search, making them suitable for large-scale historical data environments.

[0118] Status fields can be maintained through business-side tag injection, such as real-time updates based on user actions (e.g., a "Terminate Conversation" button), automatic updates based on system timeout logic (e.g., "automatically expires after 7 days of no interaction"), or batch updates based on data cleansing policies. Expiration time fields can be configured through service configuration to adapt to the conversation lifecycle of different business scenarios. For example, financial risk control conversations may only be retained for 48 hours, while medical consultation conversations may be retained for one week.

[0119] This embodiment combines semantic parsing with a historical conversation semantic mapping structure to efficiently retrieve and determine the validity of historical conversations without relying on exact keyword matching. This intelligently associates interaction requests with historical data, providing an accurate source of information for constructing the context for subsequent conversations. Furthermore, a status and expiration mechanism effectively prevents interference from invalid historical data, improving overall conversation management accuracy and system stability.

[0120] In one embodiment, the above step S30 includes:

[0121] S301: If the interaction request is associated with a stored historical session identifier, query a database for all historical session metadata associated with the historical session identifier, where the historical session metadata includes a session identifier, a creation time field, and a data storage address;

[0122] S302, generating a metadata list arranged in descending order of creation time based on the creation time field in the historical session metadata;

[0123] S303, extracting all data storage address fields from the sorted metadata list to form a data loading address queue;

[0124] S304, sequentially accessing each storage address in the data loading address queue, and extracting historical session data corresponding to each storage address from the database;

[0125] S305, accumulating the total number of bytes of the extracted historical session data, and terminating the data extraction operation when the total number of bytes reaches the preset capacity threshold;

[0126] S306: Mark the extracted historical session data as an extracted set, and mark the remaining storage address fields that have not been accessed in the data loading address queue as a non-extracted state.

[0127] In this embodiment, after determining that the user's current interaction request is associated with a stored historical session identifier, the system needs to extract the historical data associated with that identifier in chronological order. Before performing data extraction, the system first queries the database for all historical session metadata associated with the historical session identifier. The metadata structure should include a unique identifier field for the session, used to identify the corresponding conversation; a creation time field to support time-based sorting logic; and a data storage address field to locate the physical or logical storage location of the historical data during subsequent data extraction. This type of metadata is typically stored in a dedicated metadata index table, which can be quickly retrieved using the database's indexing mechanism.

[0128] All extracted historical metadata must be sorted by the creation time field in ascending chronological order, starting with the oldest conversation record. The sorting results are not directly used in data retrieval, but serve as the basis for constructing an ordered data loading address queue. This queue consists solely of the data storage address fields extracted from the sorted metadata. Its structure ensures that subsequent data retrieval operations are always performed in chronological order.

[0129] The system sequentially traverses the data loading address queue, accessing the corresponding historical session data from each address. Each extraction operation is accompanied by a byte count operation. That is, for each historical data entry, the byte length of that data is added to the currently accumulated number of extracted bytes. This accumulation process is performed in local memory, and the memory structure is used to determine in real time whether the set capacity limit has been exceeded. If the accumulated byte count does not exceed the set threshold, the data corresponding to the next address is extracted. If the accumulated value reaches or exceeds the threshold, the reading process is immediately terminated to ensure that an overload is not triggered.

[0130] After extraction is complete, the system constructs the read historical data into a set, defined as the extracted set, which is subsequently used to construct context parameters. Meanwhile, unread address items remain in the load address queue, their status explicitly marked as unextracted to facilitate future incremental reads on demand. This state-differentiated logic supports asynchronous data loading and partial reuse, improving system processing flexibility.

[0131] The data ingestion capacity threshold can be set in system initialization parameters or dynamically configured at the start of a user session. For example, in resource-constrained inference model scenarios, a smaller threshold (e.g., 64KB) can be used to control input length; whereas in resource-rich deployment scenarios, a larger threshold (e.g., 256KB) can be used to allow the model to retain a larger conversation memory.

[0132] Historical session metadata queries can be performed using SQL statements with conditional filtering, such as SELECT * FROM the metadata table WHERE session ID = X. Efficient filtering and sorting are achieved by establishing a joint index based on session ID and creation time. Sorting can be performed using the database's native ORDER BY syntax or using a stable in-memory sorting algorithm (such as merge sort).

[0133] The data storage address can be a logical path (such as a database partition + primary key) or an object storage path (such as an S3 address or a distributed file system path). For large conversation data, it is recommended to use a file block structure, where each address corresponds to a data fragment, to improve manageability and network transmission efficiency.

[0134] When extracting data, the system can use a streaming read method, measuring the number of bytes as it reads. When the total number of bytes approaches a threshold, an early stopping mechanism (such as an early buffering mechanism) can be used to prevent critical overflow. After data extraction is completed, the extracted and unextracted status information is synchronously written to the task management module to ensure data consistency upon the next request.

[0135] This embodiment constructs a chronologically ordered data loading queue and employs a byte-capacity constraint mechanism to control the amount of historical conversation data loaded. This allows the system to maintain contextual coherence across multiple conversations while avoiding performance degradation or model reception anomalies caused by excessively long input content. This makes it particularly suitable for resource-constrained reasoning tasks. The state differentiation mechanism also supports incremental data loading and recovery, enhancing the processing flexibility of the multi-turn conversation system in various application scenarios.

[0136] In one embodiment, before step S40, the method further includes:

[0137] S401, detecting the character length of the response data of each record item in the extracted historical session data;

[0138] S402: If it is detected that a lengthy record item exists in the extracted historical conversation data, and the length of the response data exceeds a preset character length threshold, the complete response data of the lengthy record item is sent to the intelligent processing module to request generation of summary information of the lengthy record item;

[0139] S403: Receive the summary information returned by the intelligent processing module, and replace the response data content of the lengthy record item in the extracted historical session data with the summary information.

[0140] In this embodiment, before combining the current interaction request with existing historical session data to form a new context input, the content length of the extracted historical data needs to be evaluated to avoid directly introducing overly long response text into the model input. To this end, the response data portion of each record in the extracted historical session data is examined one by one, and the number of characters in each response text is counted and compared with a preset character length threshold.

[0141] This character length threshold is typically set based on the maximum acceptable length of downstream inference modules to prevent the overall context construction process from exceeding the model input limit. If the response text length of a record exceeds the set value, the record is marked as lengthy and is not directly used for context construction. Instead, it is processed through summary generation.

[0142] The summary generation process is completed by an intelligent processing module, which receives the full response text of the lengthy record as input and outputs a compressed summary based on a natural language generation model. The generated summary should retain the core semantics and key information points of the original response while significantly reducing the number of characters to make it suitable for the subsequent context construction step.

[0143] Once the compressed summary content is received, the system performs a replacement operation within the original record structure, preserving the original record's metadata, such as timestamps and role identifiers, and replacing only the response content fields with the summary text. The replaced record remains in the historical session data set and is treated as a compressed response fragment for subsequent contextual splicing. This replacement operation ensures that the overall character size of the response data is controlled without losing the integrity of the contextual time series.

[0144] In actual deployments, the character length threshold can be dynamically configured. For example, the maximum character length for different task types can be set in a configuration file when launching a task, or it can be adjusted by the user or system administrator through the front-end interactive configuration panel. Response data character length detection can be implemented by iterating through the history record one by one and calling a standard character count function.

[0145] The summary generation module can be implemented based on a specially trained compression model, such as using the TextRank algorithm for key sentence extraction or using a pre-trained language model based on the Transformer architecture for semantic compression. During the summary generation process, length control parameters or sentence weight screening mechanisms can be added to ensure that the output meets the required compression ratio.

[0146] Replacement operations are typically performed in the local cache, meaning the record content is updated in-place before context parameters are generated, avoiding impacting the original data table. In systems that support version control, a hash value or version identifier of the original response can also be retained for subsequent verification or tracing.

[0147] This embodiment uses a mechanism to pre-detect and replace lengthy response records, enabling the system to maximize the preservation of conversational semantics when constructing model context while avoiding truncation or overflow issues caused by excessive character counts. While preserving chronological order, it effectively compresses the input size, allowing more valuable historical content to contribute to the understanding of the current conversation, thereby improving the accuracy and contextual consistency of response generation.

[0148] In one embodiment, the above step S40 includes:

[0149] S404, adding a requester role identifier and a responder role identifier before each piece of extracted historical session data;

[0150] S405, arranging the historical session data after adding the role identifier into a historical data sequence in descending order of creation time;

[0151] S406, inserting a context topic description sentence of the current conversation at the beginning of the historical data sequence;

[0152] S407, adding the interaction request to the end of the historical data sequence after the context topic description statement is inserted, and adding the requesting party role identifier before the interaction request;

[0153] S408: Convert the historical data sequence to which the interaction request has been added into a continuous text stream, and encode the continuous text stream into an input data format compatible with the intelligent processing module.

[0154] In this embodiment, in order to ensure that the current interaction request can be correctly understood by the intelligent processing module on the basis of accurately restoring the conversation context, it is necessary to structurally splice the interaction request with the previously extracted historical conversation data to construct continuous input content that meets the semantic reasoning requirements. During the splicing process, the format of the historical conversation data is first standardized, that is, role identification information is appended before each extracted historical record to indicate whether the content is generated by the user or the system, thereby providing the necessary semantic guidance for the subsequent model to construct the conversation turn structure. The role identifier can use a fixed label (such as [USER] or [SYSTEM]), or it can be automatically inferred from the record metadata based on a preset mapping relationship.

[0155] After character labeling, the historical records are sorted in ascending order by creation time, stitching together different rounds of conversation into logically coherent text segments. This sorting operation is based on the timestamp field in each historical record, ensuring that the semantic flow conforms to the natural unfolding of human conversation. The resulting sequence becomes the historical data foundation for the current context.

[0156] Insert a topic prompt for the current conversation at the beginning of the historical data sequence to clearly indicate the current conversation context or the scope of the user's intent to the model. For example, if a user wants to ask multiple questions about a specific product optimization, the topic description could be "Current topic: Gathering suggestions for improving product A's performance." This statement guides the model to focus on the specific intent scope and reference relevant context.

[0157] Next, the current interaction request content is concatenated to the end of the historical data sequence, and a role identifier corresponding to the user role is prepended to it. This clarifies the position of the current question in the conversation structure, forming a clear question evolution path from start to development to current, providing structural constraints for subsequent response generation.

[0158] Finally, the concatenated conversation text stream is converted into a continuous input string and encapsulated into a compatible format based on the requirements of the connected intelligent processing module. This format may include a labeled sequence of tokens, structured input based on ChatML or JSON, or a lightweight format separated by line breaks and control characters, depending on the model platform's supported protocols. During the conversion process, elements such as role identifiers, chronological order, and semantic labels must not be omitted or tampered with to prevent semantic drift or model interpretation errors.

[0159] In a real-world system, to effectively integrate interaction requests with historical conversation data, a message preprocessing module can be used in conjunction with a context builder module. First, the system calls the message preprocessing module to sequentially read the historical conversation data extracted from the database. Each record contains a timestamp, interaction role, and request or response text. A field parsing function extracts the main text content, and the corresponding role identifier is automatically matched based on the role field. For example, if a field indicates "user input," the [USER] tag is inserted before the text; if it indicates "system response," the [SYSTEM] tag is inserted.

[0160] After the role labeling is completed, all records are sorted in ascending order using the time field. The sorting operation can be performed in the cache to avoid writing pressure on the original data table. After the sorting is completed, the sorted historical records are used as the basic context data. To highlight the semantic goals of the current conversation, the front-end or middleware generates a structured topic prompt. This prompt can be automatically generated by a predefined intent classification model or constructed based on keywords extracted from user input. For example, when a user is consulting a business process, a topic guide such as "Current Topic: Business Process Optimization Recommendation Analysis" can be generated.

[0161] The current interaction request content is appended to the end of the historical record, still modified with role tags such as [USER]. After all text segments are concatenated, they are uniformly passed to the context builder module for format conversion, using system-supported format specifications (such as structured JSON or customized control character sequences) to complete the final context text encoding. The context builder can also make compression decisions based on word count or token length limits. If the length limit is exceeded, low-weight historical records are preferentially discarded to control length. This ensures that the integrated context meets the model input specifications while retaining high-value content.

[0162] For example, in the healthcare field, multiple conversations between users and the system might revolve around a chronic disease treatment plan, such as "Managing the side effects of hypertension medication." The system reconstructs historical questions and answers, such as "I feel dizzy after taking a certain medication," and the system's response, "It is recommended to monitor blood pressure changes," into a structured context in chronological order. Combined with the user's latest question, "Can I change medications?", this completes the semantic chain, providing a clear context for the intelligent model to generate targeted recommendations.

[0163] In financial services, customers may engage in multiple rounds of inquiries regarding the loan approval process, leaving historical records with information such as "How long does approval take?" and "What documents were submitted?" The system tags all records with roles and sorts them by time, then adds a guideline, "Current Topic: Loan Progress Tracking." It then concatenates the most recent interaction at the end and feeds it into the model. Even if the model itself lacks the ability to manage extended conversations, it can accurately identify customer needs through externally reconstructed context, enabling seamless intelligent services.

[0164] This embodiment significantly improves the intelligent processing module's ability to understand multiple rounds of context by splicing the current interaction request with the extracted historical conversation data in a structured form and adding role identification and sequence information to each piece of data. The ordering and role labeling of historical data ensure the clarity of semantic progression, while the insertion of topic prompts enhances the target focus of the request, enabling the model to accurately infer the context of the current question based on the context when faced with complex conversations, thereby improving the quality of the response. At the same time, the text stream encoding step adapts the final context parameters for compatibility, ensuring that no format mismatch or content truncation occurs during data transmission, thereby improving system stability and response consistency.

[0165] In one embodiment, after the above step S50, the method further includes:

[0166] S501, combining the complete content of the interaction request, the complete content of the second response data, the current session identifier, and the timestamp field into session record data to be stored;

[0167] S502, allocating a unique serialization identifier to the session record data, and associating and binding the serialization identifier with the current session identifier;

[0168] S503, writing the session record data into a corresponding time partition storage unit of the database according to the value of the timestamp field;

[0169] S504: Add the serialization identifier, current session identifier, and timestamp field to the session index table of the database to establish a searchable mapping relationship between the serialization identifier, current session identifier, and timestamp field.

[0170] In this embodiment, after the intelligent processing module generates the response content, the request and response data generated by the interaction need to be structured and stored to support subsequent conversation tracing, context building, or data auditing. First, the interaction request and generated response data need to be encapsulated, including the original user question text, the model return text, the current conversation session identifier, and the system-generated timestamp field. These fields together form a persistent structured data unit.

[0171] To ensure that each session record is uniquely searchable within the database, the system generates a globally unique serialized identifier using a high-precision incrementing sequence, timestamp encoding, or a UUID mechanism. This identifier is bound to the current session identifier, forming a one-to-one correspondence. This allows each record to both belong to a specific session and possess an independent identity.

[0172] Next, the system determines the time partition storage unit to which the record belongs based on the timestamp field in the record. Common partition granularities include hours, days, or weeks, and the partition path can be calculated using the dynamic partition mapping rules in the database. Before the record is written, a format check and field completion process can be performed in the intermediate cache to ensure record integrity. After the data is written, the record's serialization identifier, session identifier, and timestamp fields are synchronously registered in the session index table. This index table is an auxiliary query structure that supports retrieving session records by time interval, restoring context tracks by session identifier, and precisely locating individual interaction content by serialization identifier.

[0173] At the technical deployment level, a data writing link can be constructed based on the middleware event stream. Whenever a user interaction is completed and the intelligent module returns a result, the server-side logger will pass the interaction data to the structured encapsulation module. This module uses a unified field template to encapsulate the request text, response text, session identifier, and system-generated time into a standard structured object. Once encapsulated, the unique identifier generator is called to generate a 64-bit long integer identifier, which is attached to the structured data and used as the primary key.

[0174] Encapsulated data is partitioned and path-based based on the time field, for example, using a "year-month-day" format. When data is written, it is connected to the corresponding partition node through a database driver, supporting automatic partition expansion. After the data is stored on disk, the system writes the identifier, along with the session ID and timestamp fields, into a dedicated index table. The index table uses a B+ tree or hash table structure to optimize query performance.

[0175] When the system needs to restore the conversation context or generate a report from a specified session, it can query the index table using the session ID + time range combination to obtain the required record set, improving recovery efficiency and reducing the database scanning burden.

[0176] This embodiment ensures a close connection between interactive content and structural metadata through structured record writing logic, enabling each user interaction to be accurately identified through unique identifiers and, combined with the time dimension, archived, restored, or tracked. A partitioned storage strategy further improves writing and retrieval efficiency, while an index mapping mechanism ensures fast access under multi-dimensional conditions.

[0177] In one embodiment, the above step S60 includes:

[0178] S601, obtaining a sensitive word matching strategy and a corresponding replacement template from a preset filtering strategy library;

[0179] S602: Identify the text content of the first response data or the text content of the second response data to determine sensitive keywords that match the sensitive word matching strategy;

[0180] S603: Replace sensitive keywords matched in the text content of the first response data or the text content of the second response data with desensitized placeholders or desensitized generalized expressions according to a replacement template corresponding to the sensitive word matching strategy;

[0181] S604, verifying whether the desensitized first response data or the second response data complies with the data security transmission protocol;

[0182] S605: Output the first response data or the second response data that has passed the verification to the interactive interface.

[0183] In this embodiment, before outputting the response data, sensitivity identification and information desensitization are performed on its text content to meet data compliance requirements and transmission security standards. First, the system extracts sensitive word matching strategies and corresponding replacement templates from an internally defined filtering policy library. This policy library is typically stored in the form of a structured table or hash map. Each set of matching strategies and replacement templates constitutes a key-value mapping, supporting multi-language and multi-business domain configuration.

[0184] Matching strategies define the rules for identifying sensitive words, which can include keyword lists, regular expressions, context-dependent rules, and other types. Replacement templates specify the desensitization format for corresponding sensitive words, such as replacing them with a uniform placeholder like "***" or replacing the original data with a fuzzy expression like "a certain ID number."

[0185] Desensitizing generalized representations protects sensitive content in response data by replacing the original sensitive words with generic descriptions that have relevant semantics but lack precise information. Compared to directly masking sensitive content with placeholders such as "***" or "[Desensitized]," generalized representations conceal sensitive content while retaining certain semantic information, helping to enhance user comprehension. For example, "Zhang San" can be generalized to "a certain customer," "China Merchants Bank" to "a certain financial institution," and "October 12, 2023" to "a certain time period." This approach maintains contextual integrity and readability while ensuring the information is unidentifiable. This approach has practical applications in both healthcare and finance. For example, in medical reports, "Wang Moumou, male, 45 years old" can be translated as "a certain middle-aged male patient," and in financial transaction records, "account number ending in 1234 paid 10,000 yuan" can be translated as "a certain user made a large payment." This desensitizing and generalized processing method is suitable for scenarios with a higher risk of information leakage. It can improve data compliance while maintaining the interactive experience and semantic coherence of the conversation content.

[0186] After extracting text from the first or second response data generated by the model, the system uses word-by-word scanning and window context analysis to identify sensitive keywords and compares them with the matching strategy. Successfully matched terms are located at specific locations in the original text.

[0187] The replacement process completes the text replacement according to the corresponding template. This process should maintain the semantic coherence of the text as much as possible and not disrupt the syntactic structure. For example, if the original sentence is "User ID number is 3403...", it should be replaced with "User ID number is ***", preserving the main semantic content and masking sensitive content.

[0188] After desensitization is complete, the system performs protocol-level transmission validation on the processed response data. This validation may include whether the desensitization markup is standardized, whether any fields are missing, whether the character encoding meets the protocol standard of the interactive front-end (such as UTF-8), and whether the field structure matches the predefined interactive format.

[0189] Finally, the anonymized response data that passes all verifications will be written into the front-end interactive channel and displayed on the user interface to ensure that the output data is both complete and compliant.

[0190] Furthermore, after receiving the first or second response data, the system first uses the sensitive information detection component to identify the text. This component uses a pre-trained named entity recognition model (such as BERT-NER or BiLSTM-CRF) and a rule base to identify sensitive entities such as names, ID numbers, mobile phone numbers, addresses, organization names, and time points. This recognition process not only supports literal matching but also incorporates context-dependent semantic understanding to ensure coverage of aliases and synonyms. After recognition, the generalization replacement phase begins. The system pre-builds a semantic mapping table from sensitive entities to generalized expressions, such as "person name → user," "company name → organization," "detailed time → time period," and "specific amount → amount range." For each sensitive entity identified, the system selects a corresponding generalization template from the mapping table to replace the original text. For example, the original sentence "Zhang San transferred 10,000 yuan at China Merchants Bank on March 5, 2023" would be processed as "A user transferred a certain amount at a certain financial institution during a certain time period." To improve the naturalness of expression, the system can introduce a context-sensitive generalized template selection mechanism. Based on the tone, sentence structure, and context of the original sentence, it dynamically selects alternative expressions that are more consistent with the semantic grammar. For example, "Please contact Dr. Wang Qiang" can be processed as "Please contact relevant medical personnel" instead of the blunt "Please contact someone." In addition, a desensitizing labeling mechanism can be introduced to add a machine-readable identifier to each generalized field, such as "a user [entity=user]", to facilitate log tracking and auditing.

[0191] In one specific embodiment, after receiving the response text from the dialogue generation model, the system uses an embedded entity recognition component to parse sensitive fields. This recognition component employs a dual-channel design: keyword rules are used to quickly capture fixed-format fields such as phone numbers, ID numbers, and bank card numbers. Furthermore, a contextual semantic model is used to understand and recognize semantically sensitive fields such as names, places, and organizations. Once sensitive fields are identified, the system enters the generalization phase. Fields are mapped to a preconfigured set of desensitized expressions, with each type of sensitive information assigned a corresponding generalization level and expression template. For example, ID numbers can be uniformly mapped to "a certain ID number," while organization names such as "a certain hospital" are replaced with "a medical institution" based on the context. This mapping rule supports regular expression enhancement and contextual conditional analysis, and allows for configuration of priority weights. To avoid semantic incoherence, the system invokes a semantic repair module after generalization replacement to adjust the replaced sentences for linguistic coherence. This module uses a language model to detect syntactic breaks or logical jumps and reconstructs word order while preserving generalized labels, ensuring that the output text is both compliant and natural. After completing the desensitization and generalization, the system will synchronously package the response content and the user session identifier, connect to the output management service, and push the desensitized content to the user interaction interface in an asynchronous or real-time manner. If it is found during the compliance verification process that the output contains ungeneralized fields, an alarm will be triggered and the output will be terminated to ensure data security and integrity. It is also possible to set up multi-layer desensitization strategies based on the sensitivity level of different business scenarios. In the high-sensitivity level mode, a stricter desensitization scope and a more abstract generalization expression are enabled. For example, "Zhang San applied for a claim of 10,000 yuan on March 15, 2023" can be generalized to "the user applied for a claim at a certain time."

[0192] Example: In an intelligent customer service system, a bank user initiates a consultation request through a mobile app, asking, "How is the interest on my credit card bill calculated?" Upon receiving this interactive request, the system uses natural language parsing to extract the intent label "bill interest explanation" and the key entities "credit card," "interest," and "bill." The system accesses the semantic association mapping table and discovers multiple records in the user's historical conversations related to "interest explanation" and "bill details." Some of these historical records are lengthy. Based on character length, the system triggers the summary generation module, which condenses some historical responses and replaces the original content. The consolidated historical conversation data is sorted by time, with role identifiers and contextual topic descriptions inserted. The current request information is appended to the end of the historical data to complete the context parameters. Based on the context parameters, the intelligent processing module generates a new response: "Credit card bill interest is calculated at 0.05% of the daily outstanding balance, accruing monthly." Because the output content involves amount calculation rules, the system applies a sensitive word matching strategy before output. Keywords like "interest" and "0.05%" trigger a generalized template, converting them to "the bank's standard interest rate" to reduce the risk of misunderstanding and verify that the response complies with data output security policies. The final output results are packaged and stored in the database, and an index mapping is created. If the user asks a similar question again in the future, the system will prioritize retrieving the existing conversation records to continue the conversation.

[0193] In the intelligent medical consultation platform, a user enters the question, "My mother's white blood cell count was low during a checkup last week. Can she still get vaccinated?" Upon receiving the request, the system immediately analyzes the text semantics and extracts the intent label "vaccine suitability" and the key entities "low white blood cell count," "vaccine," and "examination." A semantic association mapping table identifies the user's previous inquiries, including those mentioning related keywords such as "chemotherapy" and "immunosuppression." The system extracts the associated conversation content and loads it in chronological order. Since some historical records are too long, the system automatically invokes a summary generation model to extract core information and replace lengthy paragraphs. When constructing context parameters, the system tags the roles of the historical conversations and the current request, inserts a topic description ("Consultation on the relationship between low white blood cell count and vaccination") at the beginning, and then submits it to the intelligent diagnosis module. The module returns an initial response: "If the patient has recently received immunosuppressive therapy, it is recommended to postpone vaccination. The specific decision is based on the blood routine test results." This response contains the clinical terms "immunosuppression" and "blood routine." The system uses a pre-set filtering strategy to check whether these medical keywords cross the sensitive threshold. If no privacy content is found, the system determines that the response can be directly output. The interaction is then structured and stored in the database, partitioned by timestamp. The serialized identifier, timestamp, and user session ID are written into an index table for quick subsequent association. If the user subsequently adds, "My blood test has returned to normal, can I get vaccinated?" the system automatically identifies this as the same conversation thread and loads the current conversation context, ensuring a continuous response of medical knowledge.

[0194] This embodiment effectively solves the compatibility problem of sensitive information leakage risk and incoherent response text by performing desensitization processing based on semantic recognition and generalized templates before outputting the response data. Without relying on the model itself to implement multiple rounds of compliance control, this processing mechanism can add an independent semantic desensitization link between the session generation result and the user's reception. Compared with the traditional static rule shielding method, it has the advantages of flexible generalization level, strong context adaptability, and high configurability. It can simultaneously meet the dual needs of session output security and semantic integrity in fields such as medical health, financial transactions, etc. that have extremely high requirements for user privacy. Ultimately, it ensures that the system meets data compliance and security requirements while maintaining the generation effect.

[0195] In one embodiment, a conversation processing device based on historical conversation recognition is provided, which corresponds one-to-one to the conversation processing method based on historical conversation recognition in the above embodiment. Figure 3 , Figure 3 This is a functional module diagram of a preferred embodiment of a conversation processing device based on historical conversation recognition according to the present invention. It includes a conversation recognition module 10, a response generation module 20, a historical data extraction module 30, a context construction module 40, a context response module 50, and a result output module 60. Each functional module is described in detail below:

[0196] The session identification module 10 is configured to receive an interaction request and determine whether the interaction request is associated with a stored historical session identifier;

[0197] a response generating module 20 configured to send the interaction request to the intelligent processing module to generate first response data if the interaction request is not associated with a stored historical session identifier;

[0198] a historical data extraction module 30 configured to extract, if the interaction request is associated with a stored historical session identifier, historical session data associated with the historical session identifier from a database in chronological order of creation of the historical sessions, and terminate the extraction operation when the total number of bytes of the extracted historical session data reaches a preset capacity threshold;

[0199] A context building module 40 is configured to integrate the interaction request and the extracted historical session data into context parameters;

[0200] A context response module 50, configured to submit the context parameters to the intelligent processing module and receive second response data returned by the intelligent processing module;

[0201] The result output module 60 is configured to output the first response data or the second response data.

[0202] In one embodiment, the session identification module 10 is specifically configured to:

[0203] Receive an interaction request, perform natural language parsing on the text content of the interaction request, and extract a core intent tag and a key entity set of the interaction request from the text content of the interaction request;

[0204] Comparing the core intent label and key entity set with a session semantic association mapping table in a database, wherein the session semantic association mapping table stores a historical core intent label and a historical key entity set corresponding to each historical session identifier;

[0205] If the core intent tag of the interaction request is consistent with or semantically similar to a historical core intent tag of a historical session identifier in the session semantic association mapping table, or if the key entity set of the interaction request overlaps with a historical key entity set of a historical session identifier, then mark the historical session identifier as a candidate association session identifier;

[0206] Filtering historical session identifiers that are valid and not expired from the candidate associated session identifiers;

[0207] If at least one valid and unexpired historical session identifier is screened out, it is determined that the interaction request is associated with the stored historical session identifier; otherwise, it is determined that the interaction request is not associated with a valid historical session identifier.

[0208] In one embodiment, the historical data extraction module 30 is specifically configured to:

[0209] If the interaction request is associated with a stored historical session identifier, querying a database for all historical session metadata associated with the historical session identifier, the historical session metadata including the session identifier, a creation time field, and a data storage address;

[0210] Generating a metadata list arranged in descending order of creation time according to the creation time field in the historical session metadata;

[0211] Extract all data storage address fields from the sorted metadata list to form a data loading address queue;

[0212] Accessing each storage address in the data loading address queue in sequence, and extracting historical session data corresponding to each storage address from the database;

[0213] Accumulating the total number of bytes of the extracted historical session data, and terminating the data extraction operation when the total number of bytes reaches the preset capacity threshold;

[0214] The extracted historical session data is marked as an extracted set, and the remaining storage address fields that have not been accessed in the data loading address queue are marked as a non-extracted state.

[0215] In one embodiment, the context building module 40 is specifically configured to:

[0216] Detect the character length of the response data of each record item in the extracted historical session data;

[0217] If it is detected that there is a lengthy record item in the extracted historical conversation data, whose response data character length exceeds a preset character length threshold, sending the complete response data of the lengthy record item to the intelligent processing module to request generation of summary information of the lengthy record item;

[0218] The summary information returned by the intelligent processing module is received, and the response data content of the lengthy record item in the extracted historical session data is replaced with the summary information.

[0219] In one embodiment, the context building module 40 is specifically configured to:

[0220] Add the requester role identifier and responder role identifier before each extracted historical session data;

[0221] Arrange the historical session data after adding the role identifier into a historical data sequence in descending order of creation time;

[0222] Inserting a context topic description sentence of the current session at the beginning of the historical data sequence;

[0223] Adding the interaction request to the end of the historical data sequence after the context topic description sentence is inserted, and adding a requester role identifier before the interaction request;

[0224] The historical data sequence to which the interaction request has been added is converted into a continuous text stream, and the continuous text stream is encoded into an input data format compatible with the intelligent processing module.

[0225] In one embodiment, the context response module 50 is specifically configured to:

[0226] Combining the complete content of the interaction request, the complete content of the second response data, the current session identifier, and the timestamp field into session record data to be stored;

[0227] Allocating a unique serialization identifier to the session record data, and associating and binding the serialization identifier with the current session identifier;

[0228] Writing the session record data into a corresponding time partition storage unit of the database according to the value of the timestamp field;

[0229] The serialization identifier, current session identifier and timestamp fields are added to the session index table of the database to establish a searchable mapping relationship between the serialization identifier, current session identifier and timestamp fields.

[0230] In one embodiment, the result output module 60 is specifically configured to:

[0231] Obtain sensitive word matching strategies and corresponding replacement templates from the preset filtering strategy library;

[0232] Identifying the text content of the first response data or the text content of the second response data, and determining sensitive keywords that match the sensitive word matching strategy;

[0233] Replacing the sensitive keywords matched in the text content of the first response data or the text content of the second response data with desensitized placeholders or desensitized generalized expressions according to a replacement template corresponding to the sensitive word matching strategy;

[0234] Verify whether the desensitized first response data or second response data complies with the data security transmission protocol;

[0235] The first response data or the second response data that passes the verification is output to the interactive interface.

[0236] In one embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as follows: Figure 4 As shown. The computer device includes a processor, memory, network interface and database connected via a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external user terminal via a network connection. When the computer program is executed by the processor, it implements the functions or steps on the server side of a conversation processing method based on historical conversation recognition.

[0237] In one embodiment, a computer device is provided. The computer device may be a user terminal, and its internal structure diagram may be as follows: Figure 5As shown. The computer device includes a processor, memory, network interface, display screen and input device connected via a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external server via a network connection. When the computer program is executed by the processor, it implements the functions or steps on the user side of a conversation processing method based on historical conversation recognition.

[0238] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the following steps are performed:

[0239] receiving an interaction request, and determining whether the interaction request is associated with a stored historical session identifier;

[0240] If the interaction request is not associated with a stored historical session identifier, sending the interaction request to an intelligent processing module to generate first response data;

[0241] If the interaction request is associated with a stored historical session identifier, extracting historical session data associated with the historical session identifier from the database in the order of creation time of the historical sessions, and terminating the extraction operation when the total number of bytes of the extracted historical session data reaches a preset capacity threshold;

[0242] Integrating the interaction request with the extracted historical session data into context parameters;

[0243] Submitting the context parameters to the intelligent processing module and receiving second response data returned by the intelligent processing module;

[0244] The first response data or the second response data is output.

[0245] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the following steps are implemented:

[0246] receiving an interaction request, and determining whether the interaction request is associated with a stored historical session identifier;

[0247] If the interaction request is not associated with a stored historical session identifier, sending the interaction request to an intelligent processing module to generate first response data;

[0248] If the interaction request is associated with a stored historical session identifier, extracting historical session data associated with the historical session identifier from the database in the order of creation time of the historical sessions, and terminating the extraction operation when the total number of bytes of the extracted historical session data reaches a preset capacity threshold;

[0249] Integrating the interaction request with the extracted historical session data into context parameters;

[0250] Submitting the context parameters to the intelligent processing module and receiving second response data returned by the intelligent processing module;

[0251] The first response data or the second response data is output.

[0252] It should be noted that the above functions or steps that can be implemented by the computer-readable storage medium or computer device can be found in the relevant descriptions of the server side and the user side in the aforementioned method embodiment. To avoid repetition, they will not be described one by one here.

[0253] Those skilled in the art will appreciate that all or part of the processes in the above-mentioned embodiments can be implemented by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0254] Those skilled in the art will clearly understand that for the sake of convenience and brevity of description, only the division of the above-mentioned functional units and modules is used as an example. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0255] It should be noted that if any software tools or components other than those of the Company appear in the embodiments of this application, they are merely for illustration and do not represent actual use. The above embodiments are intended only to illustrate the technical solutions of the present invention, not to limit them. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the above embodiments, or replace some of the technical features therein with equivalents. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included in the scope of protection of the present invention.

Claims

1. A conversation processing method based on historical conversation recognition, characterized in that: The following steps are involved: receiving an interaction request, and determining whether the interaction request is associated with a stored historical session identifier; If the interaction request is not associated with a stored historical session identifier, sending the interaction request to an intelligent processing module to generate first response data; If the interaction request is associated with a stored historical session identifier, extracting historical session data associated with the historical session identifier from the database in the order of creation time of the historical sessions, and terminating the extraction operation when the total number of bytes of the extracted historical session data reaches a preset capacity threshold; Integrating the interaction request with the extracted historical session data into context parameters; Submitting the context parameters to the intelligent processing module and receiving second response data returned by the intelligent processing module; The first response data or the second response data is output.

2. The method for processing conversations based on historical conversation recognition according to claim 1, wherein: Receiving an interaction request and determining whether the interaction request is associated with a stored historical session identifier includes: Receive an interaction request, perform natural language parsing on the text content of the interaction request, and extract a core intent tag and a key entity set of the interaction request from the text content of the interaction request; Comparing the core intent label and key entity set with a session semantic association mapping table in a database, wherein the session semantic association mapping table stores a historical core intent label and a historical key entity set corresponding to each historical session identifier; If the core intent tag of the interaction request is consistent with or semantically similar to a historical core intent tag of a historical session identifier in the session semantic association mapping table, or if the key entity set of the interaction request overlaps with a historical key entity set of a historical session identifier, then mark the historical session identifier as a candidate association session identifier; Filtering historical session identifiers that are valid and not expired from the candidate associated session identifiers; If at least one valid and unexpired historical session identifier is screened out, it is determined that the interaction request is associated with the stored historical session identifier; otherwise, it is determined that the interaction request is not associated with a valid historical session identifier.

3. The method for processing conversations based on historical conversation recognition according to claim 1, wherein: If the interaction request is associated with a stored historical session identifier, extracting historical session data associated with the historical session identifier from the database in the order of creation time of the historical sessions, and terminating the extraction operation when the total number of bytes of the extracted historical session data reaches a preset capacity threshold, including: If the interaction request is associated with a stored historical session identifier, querying a database for all historical session metadata associated with the historical session identifier, the historical session metadata including the session identifier, a creation time field, and a data storage address; Generating a metadata list arranged in descending order of creation time according to the creation time field in the historical session metadata; Extract all data storage address fields from the sorted metadata list to form a data loading address queue; Accessing each storage address in the data loading address queue in sequence, and extracting historical session data corresponding to each storage address from the database; Accumulating the total number of bytes of the extracted historical session data, and terminating the data extraction operation when the total number of bytes reaches the preset capacity threshold; The extracted historical session data is marked as an extracted set, and the remaining storage address fields that have not been accessed in the data loading address queue are marked as a non-extracted state.

4. The method for processing conversations based on historical conversation recognition according to claim 1, wherein: Before integrating the interaction request with the extracted historical session data into context parameters, the method further includes: Detect the character length of the response data of each record item in the extracted historical session data; If it is detected that there is a lengthy record item in the extracted historical session data, the character length of the response data exceeds a preset character length threshold, sending the complete response data of the lengthy record item to the intelligent processing module to request generation of summary information of the lengthy record item; The summary information returned by the intelligent processing module is received, and the response data content of the lengthy record item in the extracted historical session data is replaced with the summary information.

5. The method for processing conversations based on historical conversation recognition according to claim 1, wherein: Integrating the interaction request with the extracted historical session data into context parameters, including: Add the requester role identifier and responder role identifier before each extracted historical session data; Arrange the historical session data after adding the role identifier into a historical data sequence in descending order of creation time; Inserting a context topic description sentence of the current session at the beginning of the historical data sequence; Adding the interaction request to the end of the historical data sequence after the context topic description sentence is inserted, and adding a requester role identifier before the interaction request; The historical data sequence to which the interaction request has been added is converted into a continuous text stream, and the continuous text stream is encoded into an input data format compatible with the intelligent processing module.

6. The method for processing conversations based on historical conversation recognition according to claim 1, wherein: After submitting the context parameters to the intelligent processing module and receiving second response data returned by the intelligent processing module, the method further includes: Combining the complete content of the interaction request, the complete content of the second response data, the current session identifier, and the timestamp field into session record data to be stored; Allocating a unique serialization identifier to the session record data, and associating and binding the serialization identifier with the current session identifier; Writing the session record data into a corresponding time partition storage unit of the database according to the value of the timestamp field; The serialization identifier, current session identifier and timestamp fields are added to the session index table of the database to establish a searchable mapping relationship between the serialization identifier, current session identifier and timestamp fields.

7. The method for processing conversations based on historical conversation recognition according to claim 1, wherein: Outputting the first response data or the second response data includes: Obtain sensitive word matching strategies and corresponding replacement templates from the preset filtering strategy library; Identifying the text content of the first response data or the text content of the second response data, and determining sensitive keywords that match the sensitive word matching strategy; Replacing the sensitive keywords matched in the text content of the first response data or the text content of the second response data with desensitized placeholders or desensitized generalized expressions according to a replacement template corresponding to the sensitive word matching strategy; Verify whether the desensitized first response data or second response data complies with the data security transmission protocol; The first response data or the second response data that passes the verification is output to the interactive interface.

8. A conversation processing device based on historical conversation recognition, characterized in that: The dialogue processing device based on historical conversation recognition includes: A session identification module, configured to receive an interaction request and determine whether the interaction request is associated with a stored historical session identifier; a response generating module, configured to send the interaction request to the intelligent processing module to generate first response data if the interaction request is not associated with a stored historical session identifier; a historical data extraction module configured to extract, if the interaction request is associated with a stored historical session identifier, historical session data associated with the historical session identifier from a database in chronological order of creation of the historical sessions, and terminate the extraction operation when the total number of bytes of the extracted historical session data reaches a preset capacity threshold; a context building module, configured to integrate the interaction request and the extracted historical session data into context parameters; a context response module, configured to submit the context parameters to the intelligent processing module and receive second response data returned by the intelligent processing module; The result output module is configured to output the first response data or the second response data.

9. A computer device, characterized in that: The computer device includes a memory, a processor, and a conversation processing program based on historical conversation recognition stored in the memory and capable of running on the processor. When the conversation processing program based on historical conversation recognition is executed by the processor, the steps of the conversation processing method based on historical conversation recognition as described in any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium, characterized in that The storage medium stores a dialog processing program based on historical conversation recognition. When the dialog processing program based on historical conversation recognition is executed by the processor, the steps of the dialog processing method based on historical conversation recognition according to any one of claims 1 to 7 are implemented.

Images