Cross-platform personalized dialogue system

Abstract

The application belongs to the technical field of artificial intelligence dialogue, and particularly relates to a cross-platform personalized dialogue system, which comprises a multi-platform access module, a platform adaptation module, a user identity unified management module and a user preference and long-term memory management module. The multi-platform access module is used as a front-end entrance of the system, and is used for establishing network communication with various front-ends and receiving heterogeneous requests sent by users. The platform adaptation module is used for performing bidirectional conversion of message formats between the heterogeneous requests received by the multi-platform access module and a unified structure inside the system, and generating standardized requests. The user identity unified management module is used for realizing mapping, binding and life cycle management of cross-platform user accounts through a global user ID based on the standardized requests. The user preference and long-term memory management module is used for centrally managing user preference and long-term memory information. The application can enable users to obtain consistent personalized experience, efficient memory utilization and controllable data security between different platforms and models.

Description

Technical Field

[0001] This application belongs to the field of artificial intelligence dialogue technology, specifically relating to a cross-platform personalized dialogue system. Background Technology

[0002] Currently, intelligent dialogue systems based on large language models are widely used in various scenarios such as web assistants, mobile application assistants, enterprise instant messaging robots, online customer service, and browser plugins. Existing dialogue systems include: chatbot systems for single platforms, multi-robot access or unified gateway systems for enterprises, dialogue systems with contextual memory, and traditional user profiling and recommendation systems. However, these systems have the following shortcomings in practical applications: 1. The same user may access the dialogue system through multiple channels such as Web, App, and enterprise IM, but each platform usually manages it only based on its own user ID or openid, lacking a unified global user identification mapping mechanism. This leads to users having to repeatedly set preferences, repeat background information, and explain long-term needs on different platforms. 2. Most systems limit "contextual memory" to the most recent rounds of dialogue, with long-term memory lacking or even becoming chaotic; although some systems store historical dialogues in databases or vector libraries, they lack filtering rules for long-term memory content, structured expression methods, and memory aging and deletion mechanisms, which easily leads to problems such as memory redundancy, low retrieval efficiency, and excessively long contexts. 3. The system often needs to interface with multiple large model services from different vendors and versions. These models differ in message format, system prompt location, and parameter support. The existing system lacks a unified abstract method for "preference to Prompt / parameter conversion," resulting in inconsistent personalized experiences for the same user across different models. 4. When calling external models, some systems directly transmit large amounts of historical dialogue or user data to third-party services, lacking mechanisms for filtering, anonymizing, and ensuring minimal transmission of the stored content. Without a controllable update and forgetting mechanism for long-term memory, users cannot understand the content recorded by the system and how it is used, posing privacy and compliance risks. 5. Existing memory logic is mostly embedded in specific business systems or platform code, failing to form an independent long-term memory management service. This leads to repeated implementation of similar functions across different business lines, resulting in high development and maintenance costs and difficulty in unified optimization.

[0003] To address the aforementioned issues, this application proposes a cross-platform personalized dialogue system, aiming to achieve cross-platform identity and preference unification, structured memory management, and unified application of personalization across multiple models. Summary of the Invention

[0004] To address the shortcomings of existing technologies, the purpose of this application is to provide a cross-platform personalized dialogue system. This application aims to achieve consistent personalized experience, efficient memory utilization, and controllable data security for users across different platforms and models by implementing cross-platform unified identity and preference management, structured long-term memory filtering and aging mechanisms, multi-model adaptation gateways, and privacy and security filtering.

[0005] To achieve the above objectives, this application provides the following technical solution:

[0006] A cross-platform personalized dialogue system includes: a multi-platform access module, serving as the system's front-end entry point, used to establish network communication with various front-ends and receive heterogeneous requests from users; a platform adaptation module, used to bidirectionally convert the message format of the heterogeneous requests received by the multi-platform access module into a unified internal structure of the system, generating standardized requests; a unified user identity management module, used to map, bind, and manage the lifecycle of cross-platform user accounts based on standardized requests and through a global user ID; and a user preference and long-term memory management module, used to centrally manage user preferences and long-term memory information.

[0007] Optionally, the multi-platform access module adopts a protocol adaptation layer architecture, employing differentiated communication protocols and connection management modes for different front-end types.

[0008] Optionally, the platform adaptation module adopts a bidirectional conversion architecture to achieve bidirectional conversion between heterogeneous platform messages and the unified internal structure of the system.

[0009] Optionally, the platform adaptation module includes: a message parsing submodule, located in the uplink, used to uniformly convert heterogeneous raw messages from different platforms into a standardized request structure; and a rendering output submodule, located in the downlink, used to convert the unified response result into a message format that can be recognized and displayed by each target platform.

[0010] Optionally, the unified user identity management module includes: an identity mapping submodule, which serves as the underlying foundation and is responsible for mapping the relationship between external user IDs and global user IDs and generating an identity mapping table; a login and binding submodule, located on top of the identity mapping submodule, which is used to trigger and change associated records in the identity mapping table through process control such as active binding, automatic matching, and preference merging; and a security control submodule, which is used to encrypt and store the mapping data in the identity mapping submodule, control access permissions, and audit operations, and also to perform security verification and log recording for key operations of the login and binding submodule.

[0011] Optionally, the login and binding submodule includes an active binding mode and an automatic matching mode.

[0012] Optionally, the security control submodule uses the AES-256-GCM algorithm to encrypt and store sensitive fields in the identity mapping table.

[0013] Optionally, the user preference and long-term memory management module includes: a user preference storage submodule, which serves as the basic data layer and is used to centrally store the user's global preference settings with the global user ID as the primary key;

[0014] The platform / model preference coverage submodule serves as the basic data layer, recording field-level preference coverage configurations for specific platforms or large models. The preference parsing and synthesis submodule acts as the upper-level logical aggregation point, dynamically reading data from the user preference storage submodule and the platform / model preference coverage submodule upon each request to generate complete preferences for the current dialogue scenario. The long-term memory storage submodule serves as the persistence center for memory data, storing long-term memory entries and their semantic vectors extracted from historical dialogues. The memory writing submodule filters content with long-term value during the dialogue process and writes it to the memory repository. The memory retrieval submodule retrieves the most relevant memories for the current question in a new round of dialogue and selects the most relevant memories for the current dialogue. The memory aging and compression submodule, as a background maintenance task, periodically calculates the comprehensive weight of memory entries, archives or deletes low-weight memories, and merges and compresses highly similar memories.

[0015] Optionally, the dialogue system also includes a dialogue management module, which is responsible for short-term context and state management of individual sessions.

[0016] Optionally, the dialogue system also includes a multi-model access gateway module for unified management of calls to multiple large models.

[0017] Compared with the prior art, the beneficial effects of this application are as follows:

[0018] (1) Achieve a consistent personalized experience across platforms;

[0019] Through a unified global user ID and centralized preference management, users can enjoy consistent personalized settings such as language, tone, and output format when accessing the same system on different platforms (Web, App, enterprise IM, etc.), without having to repeatedly configure and introduce personal information.

[0020] (2) To achieve structured and controllable management of long-term memory;

[0021] By using memory filtering, summarization, and type labeling, only content with long-term value is written into the long-term memory bank, and memory aging and compression mechanisms are used to prevent the memory from expanding indefinitely, effectively maintaining the quality of the memory bank and retrieval efficiency.

[0022] (3) Unify the reuse of preferences and memories across multiple models;

[0023] Preferences and memories are organized into an abstract structure independent of specific model implementations, and then adapted by a multi-model access gateway. This maintains consistency in personalized behavior across large models from different vendors and versions, facilitating smooth system switching or the addition of new models.

[0024] (4) Reduce context redundancy and improve generation quality and response efficiency;

[0025] By using semantic retrieval to select only the memory entries most relevant to the current question for input into the model, the transmission of all historical dialogues or a large amount of irrelevant information is avoided. This reduces both the cost and latency of invocation and minimizes the interference of irrelevant information on the model's reasoning.

[0026] (5) Enhance privacy protection and data security controls;

[0027] Adding sensitive information filtering and minimum necessary truncation mechanisms before memory injection avoids transmitting too much personal information to external model services; at the same time, memory aging and deletion strategies prevent user data from being stored indefinitely, which helps to meet privacy and compliance requirements.

[0028] (6) Provide reusable long-term memory platform capabilities.

[0029] By extracting preference and memory management from specific business logic and forming a general service interface, it can be reused by multiple applications and front-ends, reducing overall R&D and maintenance costs. Attached Figure Description

[0030] Figure 1 This is a schematic diagram of the overall structure of a cross-platform personalized dialogue system provided in this application. Detailed Implementation

[0031] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0032] It should be noted that all directional indicators (such as up, down, left, right, front, back, etc.) in the embodiments of this application are only used to explain the relative positional relationship and movement of each component in a certain specific posture (as shown in the figure). If the specific posture changes, the directional indicator will also change accordingly.

[0033] In this application, unless otherwise expressly specified and limited, the terms "connection," "fixed," etc., should be interpreted broadly. For example, "fixed" can mean a fixed connection, a detachable connection, or an integral part; it can mean a mechanical connection or an electrical connection; it can mean a direct connection or an indirect connection through an intermediate medium; it can mean the internal communication of two components or the interaction between two components, unless otherwise expressly limited. Those skilled in the art can understand the specific meaning of the above terms in this application according to the specific circumstances.

[0034] Furthermore, if the embodiments of this application involve descriptions such as "first" or "second," these descriptions are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined with "first" or "second" may explicitly or implicitly include at least one of those features. Additionally, the meaning of "and / or" throughout the text includes three parallel solutions; for example, "A and / or B" includes solution A, solution B, or a solution where both A and B are satisfied simultaneously. Furthermore, the technical solutions of the various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. When the combination of technical solutions is contradictory or impossible to implement, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed in this application.

[0035] Figure 1 This is a schematic diagram of the overall structure of a cross-platform personalized dialogue system provided in an exemplary embodiment of this application, as shown below. Figure 1 As shown, the system includes: a multi-platform access module 100, a platform adaptation module 200, a unified user identity management module 300, and a user preference and long-term memory management module 400. The multi-platform access module 100 serves as the system's front-end entry point, establishing network communication with various front-ends and receiving heterogeneous requests from users. The platform adaptation module 200 performs bidirectional conversion between the message format and the system's internal unified structure of the heterogeneous requests received by the multi-platform access module, generating standardized requests. The unified user identity management module 300, based on standardized requests, uses a global user ID to map, bind, and manage the lifecycle of cross-platform user accounts. The user preference and long-term memory management module 400 centrally manages user preferences and long-term memory information.

[0036] This embodiment achieves unified network communication for various front-ends through a multi-platform access module, completes bidirectional conversion between heterogeneous message formats and an internal unified structure through a platform adaptation module, and realizes cross-platform account mapping, binding, and lifecycle management using a unified user identity management module with a global user ID as the core. Furthermore, it relies on a user preference and long-term memory management module to centrally store and dynamically maintain preference and memory information, thereby achieving the following overall technical effects: users can obtain a consistent personalized interactive experience across different platforms without repeatedly configuring preferences or introducing personal backgrounds; long-term memory maintains high quality and a controllable scale after filtering, summarizing, aging, and compression, avoiding redundant expansion; preferences and memories are uniformly managed in a model-independent abstract form, which can smoothly adapt to various large-model services; at the same time, privacy and security are enhanced through sensitive information filtering and a minimum necessary transmission mechanism, and preference and memory management is extracted into a reusable middleware capability, reducing the repetitive development costs of multiple business systems.

[0037] In another exemplary embodiment, the multi-platform access module 100 adopts a protocol adaptation layer architecture, employing differentiated communication protocols and connection management modes for different front-end types.

[0038] In this embodiment, multiple platforms include web pages, mobile apps, enterprise instant messaging platforms (such as WeChat Work and DingTalk), browser plugins, and high-concurrency scenarios. For web pages and browser plugins, this module establishes bidirectional long connections based on the HTTPS / WebSocket protocol, maintains session state through a token authentication mechanism, and incorporates a heartbeat detection mechanism for automatic reconnection after disconnection. For mobile apps, this module supports HTTP / 2 long connections and the MQTT lightweight push protocol, ensuring real-time performance while reducing power consumption on mobile devices. For enterprise instant messaging platforms, this module adopts a Webhook callback mode, exposing a unified public network callback interface to receive messages pushed by various platforms via HTTP POST, and implementing platform signature verification (such as WeChat Work's MsgVerify) at the interface layer to ensure callback security. For high-concurrency scenarios, this module implements non-blocking I / O based on the Netty or Reactor model, manages millions of long connections with a distributed connection pool, and decouples requests for asynchronous forwarding to backend business modules through a message queue, avoiding system avalanche caused by I / O blocking.

[0039] This module employs a protocol adaptation layer architecture, selecting differentiated communication protocols and connection management modes such as HTTPS / WebSocket, HTTP / 2 and MQTT, Webhook callbacks, and Netty-based non-blocking I / O for web pages, mobile apps, enterprise instant messaging platforms, and high-concurrency scenarios. This improves the system's access compatibility, communication real-time performance, and connection stability across multiple platform environments. Simultaneously, through mechanisms such as heartbeat detection, automatic reconnection after disconnection, distributed connection pools, and asynchronous decoupling of message queues, it effectively ensures session continuity, reduces mobile device power consumption, and prevents I / O blocking and system avalanche in high-concurrency scenarios. Ultimately, this enhances the overall system scalability and high availability of the access layer.

[0040] In another exemplary embodiment, the platform adaptation module 200 adopts a bidirectional conversion architecture to realize bidirectional conversion between heterogeneous platform messages and the unified internal structure of the system. The module includes a message parsing submodule and a rendering output submodule. The message parsing submodule is located at the entry point of the uplink (platform → system) and is used to uniformly convert heterogeneous raw messages from different platforms into a standardized request structure. The rendering output submodule is located at the exit point of the downlink (system → platform) and is used to convert the unified response result into a message format that can be recognized and displayed by each target platform.

[0041] In this embodiment, the message parsing submodule adopts a converter registration mode, which is responsible for uniformly converting heterogeneous raw messages from different platforms into a standardized request structure within the system. A specific process example is as follows:

[0042] Step 1: Receive the original request data;

[0043] After receiving a platform request, the multi-platform access module passes the original request body (such as a JSON or XML format string) to the message parsing submodule.

[0044] Step 2: Identify the platform type;

[0045] Determine the source platform of the request based on the interface path identifier or the platform tag field in the request header (e.g., wecom for WeChat Work, dingtalk for DingTalk, web for web browser, etc.).

[0046] Step 3: Invoke the corresponding parser;

[0047] Based on the identified platform type, a pre-registered dedicated message converter is dynamically loaded. The converter extracts key fields from the original request, including: platform type, external user ID, message type, message text, attachment list, timestamp, session identifier, etc.

[0048] Step 4: Assemble the unified internal request object.

[0049] The extracted fields are populated into the standard internal request structure to generate a normalized request object.

[0050] During the conversion process, this submodule simultaneously performs operations such as field mapping, data type conversion, and platform signature verification to ensure the integrity and reliability of the internal structure after conversion.

[0051] Specifically, the standardized request structure within the system is exemplified as follows:

[0052] {

[0053] "request_id":"string, a globally unique request identifier automatically generated by the system, such as a UUID",

[0054] "platform_type": "string, platform type identifier, enumerated values ​​include 'web', 'ios', 'android', 'wecom', 'dingtalk', 'feishu', 'slack', 'browser_extension', etc."

[0055] "external_user_id":"string, the original user identifier of this user on the source platform",

[0056] "message_type": "string, message type, enumeration values ​​include 'text', 'image', 'file', 'voice', 'card_action', etc."

[0057] "message_text":"string, the text content sent by the user; required when message_type is 'text'".

[0058] "attachments":[

[0059] {

[0060] "type":"string, attachment type, such as 'image', 'file', 'voice'",

[0061] "url":"string, the accessible URL or temporary download address for the attachment",

[0062] "name":"string, attachment file name",

[0063] "size": "integer, attachment size (bytes)"

[0064] }

[0065] ],

[0066] "timestamp":"integer, the Unix timestamp (milliseconds) at the time the message was sent",

[0067] "session_id":"string, optional, a session identifier provided by the source platform, used to associate the same session",

[0068] "metadata":{

[0069] "raw_platform_data": "object, optional, retains other fields from the original platform request for future expansion."

[0070] }

[0071] }

[0072] The rendering output submodule adopts a structure of responsive renderer collection, which includes multiple responsive renderers. During the output stage, this submodule can load the responsive renderer corresponding to each platform based on the target platform's identifier, so as to convert the system's unified responsive objects (including text, interactive components, etc.) into a format that the target platform can recognize and display (such as rich text cards, plain text, Markdown, etc.). A specific process example is as follows:

[0073] Step 1: Read the response format characteristics;

[0074] Read the response_type and format_hints fields from the internal response object to determine the original format characteristics of the response content (such as whether it contains rich text elements such as Markdown syntax, code blocks, and tables).

[0075] Step 2: Check the platform's rendering capabilities;

[0076] Query the rendering capability configuration table of the target platform. This table predefines the message format types supported by each platform, such as: Web: Supports full Markdown (including code highlighting, tables, and LaTeX formulas); WeChat Work: Supports limited Markdown (only basic syntax such as bold, links, and lists); DingTalk: Supports Markdown and card messages; SMS channel: Only supports plain text.

[0077] Step 3: Perform format conversion;

[0078] Based on platform capabilities, the following format adaptations will be performed: If the platform supports Markdown and the content is in Markdown format, it will be passed directly; if the platform does not support Markdown, a downgrade process will be performed, such as removing Markdown tags, converting code blocks to indented text, converting tables to plain text tables or brief lists, and converting mathematical formulas to text descriptions; if the platform supports card message format, the reply content will be assembled into a card structure of "title + body + operation button" according to the platform's card message API requirements.

[0079] Step 4: Encapsulate and send the response.

[0080] The converted message body is encapsulated into the request format required by the target platform's API and then sent to the corresponding platform by the multi-platform access module.

[0081] Specifically, the structure of the response object is shown below:

[0082] {

[0083] "response_id":"string, a globally unique response identifier automatically generated by the system",

[0084] "request_id": "string, the corresponding request identifier used to associate requests and responses",

[0085] "response_type": "string, response type, enumeration values ​​include 'text', 'markdown', 'card', 'mixed', etc."

[0086] "content":"string, the response text content generated by the model",

[0087] "format_hints":{

[0088] "has_code_block": "boolean, whether the content contains a code block",

[0089] "has_table": "boolean, whether the content contains a table",

[0090] "has_latex":"boolean, whether the content contains mathematical formulas",

[0091] "suggested_format": "string, suggested output format, such as 'markdown', 'plain_text', 'rich_card'"

[0092] }

[0093] "timestamp": "integer, Unix timestamp (milliseconds) at the time the response was generated"

[0094] }

[0095] It should be noted that the platform's limitations must be considered during the rendering process described above. For example, for platforms that support rich text (such as Lark and Slack), the responsive renderer converts the internal Markdown content into a platform-specific rich text message structure; for platforms that only support plain text (such as some SMS gateways), the responsive renderer performs Markdown stripping and content truncation; for platforms that support interactive components (such as card messages in WeChat Work), the responsive renderer maps internally defined interactive elements such as buttons and forms to a platform-specific message card JSON structure.

[0096] In another exemplary embodiment, the unified user identity management module 300 includes an identity mapping submodule, a login and binding submodule, and a security control submodule. The identity mapping submodule, as the underlying foundation, is responsible for mapping the relationship between external user IDs and global user IDs and generating an identity mapping table. The login and binding submodule sits on top of it, triggering and modifying associated records in the identity mapping table through process controls such as active binding, automatic matching, and preference merging. The security control submodule, as a cross-cutting concern, encrypts and stores the mapping data in the identity mapping submodule, controls access permissions, and audits operations. It also performs security verification and log recording for key operations in the login and binding submodule. These three components form a collaborative structure of "basic support—process control—security assurance" to achieve unified, controllable, and compliant management of user identities across platforms.

[0097] In this embodiment, the identity mapping submodule establishes a many-to-one mapping relationship with the global user ID (global_user_id) using the platform type (platform_type) and external user ID (external_user_id) as a composite primary key, and generates an identity mapping table, as shown below:

[0098] Table 1 Identity Mapping Table

[0099] id BIGINT, auto-incrementing primary key Record unique identifier platform_type VARCHAR(32) Platform type identifier external_user_id VARCHAR(128) User's original ID on the platform global_user_id VARCHAR(64) System Global User ID binding_method VARCHAR(32) Binding method created_at DATETIME Creation time updated_at DATETIME Last updated id BIGINT, auto-incrementing primary key Record unique identifier platform_type VARCHAR(32) Platform type identifier

[0100] In Table 1, to ensure data consistency, a combined unique index is created on the platform_type and external_user_id fields to ensure that the same external user ID on the same platform is mapped to only one global user ID.

[0101] The login and binding submodule is responsible for managing the merging of user identities from anonymous sessions to official users, as well as the active binding and passive association between accounts across multiple platforms. Specifically, it includes the following modes:

[0102] Active Binding Mode: When a user initiates a cross-platform binding operation on any platform already logged into within this system (such as the web interface), the system generates a time-sensitive binding credential (such as a binding code or QR code). After the user enters the credential on the target platform, the system verifies it and associates the target platform's external user ID with the same global user ID.

[0103] Automatic matching mode: After a user authorizes login on a platform, the system obtains a trusted identity identifier (such as a mobile phone number or email address) from that platform and compares it with existing global user information. If the match is successful, the user is automatically bound; if it fails, a new global user ID is generated or the user is guided to manually bind the user.

[0104] Preference merging strategy mode: When multiple platform accounts are bound to the same global user ID, the preferences of the account with the earlier binding time are used as the benchmark, and field-level merging is adopted: non-conflicting fields are added in, and conflicting fields retain the benchmark value and are logged to notify the user for confirmation.

[0105] The security control submodule is responsible for encrypting and storing sensitive data in the identity mapping table, controlling access, and auditing operations. Specific measures include: 1. Field-level encrypted storage: Sensitive fields such as `external_user_id` and `global_user_id` are encrypted using the AES-256-GCM algorithm. Each encryption generates a unique random initialization vector (IV) to ensure that the same plaintext produces different ciphertexts, and an authentication tag is attached to prevent tampering. 2. Key management: Data encryption keys are generated and rotated by a unified key management service (KMS). Applications only cache keys in memory, and disk storage is strictly prohibited. 3. Database layer hardening: Transparent data encryption (TDE) is enabled for the tablespace storing the identity mapping table to prevent physical file leakage. 4. Access control and auditing: The identity mapping table is only queried externally through the encapsulated identity mapping API, and callers must possess authorization credentials. All query behaviors (caller, time, parameters) are recorded in the audit log system to meet compliance traceability requirements.

[0106] In another exemplary embodiment, the login and binding submodule includes an active binding mode and an automatic matching mode.

[0107] In this embodiment, the user-initiated binding mode (user-led) means that a user can initiate a cross-platform binding operation from any logged-in platform within this system (such as the personal settings page on the web page). The system generates a binding credential with a time limit, including but not limited to binding codes, QR codes, and binding links. After the user enters the binding credential on the target platform (or scans the QR code or clicks the link), the system verifies the validity of the credential. Upon successful verification, the external user ID of the target platform is associated with the same global user ID. This mode is initiated and confirmed by the user, offering high security and is suitable for scenarios where the user explicitly wishes to associate multiple platform accounts. The automatic matching mode means that after a user authorizes login on a platform, the system obtains the user's verified trusted identity identifier (such as a mobile phone number or email address) on that platform. The system compares this identifier with the existing global user-associated identity information as follows: if the match is successful, the current platform account is automatically bound to the existing global user ID; if the match fails, a new global user ID is generated for the current user, or the user is guided to manually bind if necessary.

[0108] In addition, the login and binding submodule provides a preference merging strategy to resolve multi-platform preference conflicts. This strategy includes the following: When two or more platform accounts are bound to the same global user ID, if each account has accumulated its own preference settings, the system merges them according to the following rules: First, a merging benchmark is set: the preferences accumulated by the account with the earlier binding time (i.e., the account that registered and bound to the global ID first) are used as the benchmark; second, a field-level merging method is adopted: for fields in the later bound account that do not conflict with the benchmark preferences, the system adds them to the global preferences; for conflicting fields (i.e., the same preference item is set with different values ​​in different accounts), the system retains the setting value of the benchmark account. Finally, conflicts are recorded and notified: all conflicting fields and their respective values ​​will be recorded in the preference conflict log. The system informs users of the existence of preference conflicts through notifications (such as system messages, emails, or in-app messages), and users confirm the final values ​​themselves. The global preferences can be updated based on the user's confirmation. This merging strategy takes into account data integrity, user control, and system automation efficiency, ensuring a smooth user experience and no loss of preferences during the multi-account merging process.

[0109] In another exemplary embodiment, the security control submodule uses the AES-256-GCM algorithm to encrypt and store sensitive fields in the identity mapping table.

[0110] In this embodiment, the security control submodule uses the AES-256-GCM algorithm to encrypt and store sensitive fields (including external_user_id and global_user_id) in the identity mapping table. The specific implementation process is as follows: 1. Field-level encryption storage: The external_user_id and global_user_id fields in each record to be written are encrypted separately. During each encryption, the system generates a unique random initialization vector (IV) to ensure that the same plaintext produces different ciphertexts in different encryption operations, thus preventing pattern analysis attacks. Subsequently, the plaintext, IV, and data encryption key obtained from the key management service are input into the AES-256-GCM algorithm. The algorithm outputs ciphertext and an authentication tag for integrity verification. Finally, the IV, authentication tag, and ciphertext are combined according to a predetermined format (e.g., IV + authentication tag + ciphertext) and stored in the corresponding field of the database to ensure that the encryption parameters can be completely restored and integrity verification can be performed during decryption. 2. Key management: The data encryption key is generated, rotated, and destroyed by a unified key management service (KMS). The application service obtains a key from KMS through secure authentication upon startup and caches it only in the application process's memory. It is strictly prohibited to store the key on disk in any form (such as writing to local files or databases) to prevent key leakage risks from the source. Third, security is strengthened at the database layer: Transparent Data Encryption (TDE) is enabled for the tablespace storing the identity mapping table at the database level, and the underlying data files are encrypted to prevent physical data leakage caused by directly reading disk files or backup media. Fourth, access is controlled and audited: The identity mapping table is not directly exposed externally; query services are only provided through a wrapped identity mapping API. Callers must possess authorization credentials, and the system verifies their identity and permissions before executing query operations. Furthermore, all query behaviors related to identity mapping data (including caller, query time, query parameters, etc.) are recorded in the audit log system to meet security audit and compliance traceability requirements.

[0111] In another exemplary embodiment, the user preference and long-term memory management module 400 includes a user preference storage submodule, a platform / model preference overlay submodule, a preference parsing and synthesis submodule, a long-term memory storage submodule, a memory writing submodule, a memory retrieval submodule, and a memory aging and compression submodule. The user preference storage submodule serves as the basic data layer, centrally storing the user's global preference settings using the global user ID as the primary key. The platform / model preference overlay submodule also serves as the basic data layer, recording field-level preference overlay configurations for specific platforms or large models. The preference parsing and synthesis submodule serves as the upper-level logical aggregation point, dynamically resolving preferences with each request. The system reads data from the two sub-modules mentioned above to generate complete preferences for the current dialogue scenario. The long-term memory storage sub-module serves as the persistence center for memory data, storing long-term memory entries and their semantic vectors extracted from historical dialogues. The memory writing sub-module filters content with long-term value during the dialogue process and writes it into the memory bank. The memory retrieval sub-module retrieves the memory most relevant to the current question in a new round of dialogue and selects the memory most relevant to the current dialogue. The memory aging and compression sub-module serves as a background maintenance task, periodically calculating the comprehensive weight of memory entries, archiving or deleting low-weight memories, and merging and compressing highly similar memories.

[0112] In another exemplary embodiment, the user preference storage submodule divides user preferences into four levels to form a structured unified user profile.

[0113] In this embodiment, the user preference storage submodule divides user preferences into four levels: interaction preferences, user background profile, interests and concerns, and interaction behavior patterns. This forms a structured, unified user profile to support personalized prompts and dynamic coverage across platforms and multi-model scenarios. The interaction preference layer represents the user's settings for the display of system output behaviors, and its code structure is shown below:

[0114] {

[0115] "language": "string, preferred interaction language, such as 'zh-CN', 'en-US', 'ja-JP'",

[0116] "tone": "string, preferred tone of voice, enumeration values ​​include 'formal', 'casual', 'professional', and 'friendly'".

[0117] "detail_level": "string, the level of detail in the response; enumeration values ​​include 'concise', 'moderate', and 'detailed'".

[0118] "prefer_code_examples":"boolean, whether you prefer to include code examples in your replies",

[0119] "preferred_programming_language":"string, the preferred programming language, such as 'Python', 'Java', 'Go', can be empty",

[0120] "output_format": "string, the preferred output format, enumerated values ​​include 'markdown', 'plain_text', and 'structured_json'",

[0121] "custom_instructions": "string, user-defined global instruction text, such as 'Please always answer in Chinese', can be empty"

[0122] }

[0123] The user background profile layer describes relatively stable attributes such as a user's professional identity, field of expertise, and knowledge level. It helps the model adjust the professional depth and expression of its responses. An example of its code structure is shown below:

[0124] {

[0125] "profession":"string, the user's profession or position, such as 'backend development engineer', 'product manager', 'university teacher'",

[0126] "industry":"string, the industry category, such as 'Internet', 'Finance', 'Education', 'Healthcare'",

[0127] "organization":"string, the name of the organization, can be empty",

[0128] "expertise_domains":["string, a list of the user's areas of expertise or interest, such as ['distributed systems', 'machine learning', 'front-end development']"],

[0129] "skill_stack":["string, a list of technologies or tools the user possesses, such as ['Java', 'SpringBoot', 'MySQL', 'Docker']"],

[0130] "knowledge_level":{

[0131] "The description key is the domain name, and the value is the knowledge level in that domain":"",

[0132] Example:{

[0133] "Python":"expert",

[0134] "Machine Learning":"intermediate",

[0135] Front-end development: "beginner"

[0136] },

[0137] "Level Enumeration Values": "beginner, intermediate, expert"

[0138] }

[0139] }

[0140] The interest and focus layer consists of user interest tags that are automatically inferred and continuously updated by the system based on historical conversations. These tags are used to proactively associate user interests with areas of interest when the model responds. An example of its code structure is shown below:

[0141] {

[0142] "topic_tags":[

[0143] {

[0144] "tag":"string, the name of the interest tag, such as 'performance optimization'",

[0145] "weight": "float, interest weight, ranging from 0.0 to 1.0, calculated based on conversation frequency and recent activity level",

[0146] "last_active_at": "integer, the Unix timestamp of the most recent mention of this tag in a conversation"

[0147] }

[0148] ],

[0149] "ongoing_projects":[

[0150] {

[0151] "project_name":"string, Project or task name, such as 'E-commerce Platform Restructuring'",

[0152] "description":"string, Project summary",

[0153] "status": "string, Project status, enumeration values ​​include 'active' (in progress), 'paused' (paused), 'completed' (completed)",

[0154] "last_mentioned_at": "integer, the Unix timestamp of the most recent mention of the project in the conversation"

[0155] } ]

[0157] }

[0158] The interaction behavior pattern layer consists of behavioral characteristics automatically collected and summarized by the system based on users' historical interaction data. Its purpose is to optimize the model's response strategy. An example of its code structure is shown below:

[0159] {

[0160] "avg_query_length": "string, the average length level of user queries, enumerated values ​​include 'short' (brief, usually less than 20 characters), 'medium' (medium), and 'long' (detailed, usually more than 100 characters)".

[0161] "preferred_response_length": "string, the user's preferred response length level, derived from user feedback statistics on responses of different lengths; enumeration values ​​are the same as above".

[0162] "frequent_use_scenarios":["string, a list of the most frequently used scenarios by users, such as ['code debugging', 'technical solution design', 'documentation writing', 'Q&A']"],

[0163] "active_time_distribution":{

[0164] "primary_timezone":"string, the user's primary active timezone, such as 'Asia / Shanghai'",

[0165] "peak_hours":["integer, a list of the most active hours of the user (24-hour format), e.g., [9, 10, 14, 15, 21]"]

[0166] }

[0167] }

[0168] The complete user profile JSON structure uses the global user ID as the primary key, organizing the above four levels into a single JSON document:

[0169] {

[0170] "global_user_id":"string, global user ID",

[0171] "interaction_preferences":{"... (first-level field)"},

[0172] "user_profile":{"... (second-level field)"},

[0173] "interests":{"... (third-level field)"},

[0174] "behavior_patterns":{"...(fourth-level field)"},

[0175] "updated_at": "integer, Unix timestamp of the most recent update time"

[0176] }

[0177] Of the four levels mentioned above, the first level (interaction preferences) and the second level (user background profile) are mainly set by the user explicitly or written after being declared in the conversation; the third level (interests and focus) and the fourth level (interaction behavior patterns) are mainly inferred and updated by the system automatically based on historical conversation data. After each conversation, the system analyzes the content of this round of conversation, extracts the relevant topic tags to update the weight and timestamp of topic_tags, identifies the mentioned project information to update ongoing_projects, and counts interaction behavior indicators to update behavior_patterns.

[0178] All fields in all levels are optional; unset fields will use the system default value or be left blank. Value types in each level are limited to string, boolean, integer, float, and arrays and single-level nested objects composed of these basic types.

[0179] During the Prompt construction phase, the system selectively extracts relevant information from the user profile based on the current dialogue scenario and injects it into the model prompts: for example, when the user asks a question involving code, information on the corresponding language from skill_stack and knowledge_level is injected to help the model match the user's technical level; when the user mentions a project, contextual information of the corresponding project from ongoing_projects is injected so that the model can continue the previous project discussion.

[0180] In another exemplary embodiment, the platform / model preference coverage submodule supports field-level preference coverage in both platform and model dimensions.

[0181] In this embodiment, the platform / model preference coverage submodule is used to record preference coverage configurations for specific platforms or models, such as compressing response length on mobile devices or forcing plain text output on models that do not support Markdown. The coverage method uses field-level coverage, meaning that only individual preference fields that need adjustment are covered; fields not explicitly specified in the configuration continue to use the corresponding values ​​from the global preferences.

[0182] In terms of priority handling, this submodule strictly follows a fixed order of "model coverage > platform coverage > global preference". When the same preference field has both platform coverage and model coverage and their values ​​are different, model coverage has the highest priority, followed by platform coverage, and global preference has the lowest priority. This design is based on the fact that model capability constraints are hard technical limitations (such as some models not supporting Markdown output), while platform display limitations can be adapted in subsequent rendering stages. Therefore, model-side coverage should take precedence over platform-side coverage.

[0183] Furthermore, coverage configurations are stored in triples, specifically including: scope type, scope identifier, and coverage preference key-value pairs. Scope types include platform (e.g., wechat_work), model (e.g., gpt-4), and model_family (e.g., llama series). Coverage priority is determined using a multi-factor sorting algorithm: first, by scope granularity, model coverage is prioritized over platform coverage, and platform coverage is prioritized over global preference; within the same scope granularity, coverage is sorted by creation time, with later-created coverage having higher priority; within the same scope, field-level merging is supported, taking the union of different configuration sources when coverage of different fields comes from different sources. In addition, coverage configurations also support conditional expressions, such as triggering verbosity=brief when network=low_speed and triggering output_format=plain_text when model_supports_markdown=false, thus achieving dynamic adaptive coverage.

[0184] In another exemplary embodiment, the preference parsing and synthesis submodule uses a hierarchical merging algorithm to generate the effective preferences for this request.

[0185] In this embodiment, the preference parsing and synthesis submodule uses a hierarchical merging algorithm to generate the effective preferences for this request, specifically including:

[0186] Step 1: Read the global preferences JSON object corresponding to the global user ID as the initial copy of the active preferences;

[0187] Step 2: Based on the platform_type of this request, query whether there is an override configuration for the corresponding platform in platform_overrides. If it exists, overwrite each field value in the platform override configuration to the effective preference copy one by one (only overwrite fields with values).

[0188] Step 3: Based on the target model identifier determined by the model routing submodule, query whether there is an override configuration for the corresponding model in model_overrides. If it exists, override each field value in the override configuration to the effective preference copy one by one (only fields with values ​​are overridden, and this step has a higher priority than step 2).

[0189] Step 4: Perform an integrity check on the synthesized active preference to ensure that all necessary fields have values ​​(missing fields are filled with system default values) and obtain the active preference object used in this request.

[0190] In another exemplary embodiment, the long-term memory storage submodule employs a hybrid storage structure.

[0191] In this embodiment, the long-term memory storage submodule is used to store long-term memory entries extracted from historical dialogues. Each memory includes structured metadata (memory type, source session, importance, creation time, etc.) and text content, and generates a corresponding semantic vector.

[0192] Specifically, the long-term memory storage submodule adopts a hybrid storage architecture: structured metadata is stored in a relational database, and semantic vectors are stored in a vector database (such as pgvector, Milvus, or an Elasticsearch vector plugin), with the two linked by a memory ID. Each memory entry contains the following metadata fields: memory_id (globally unique), global_user_id, memory_type (enumeration values: 'fact', 'preference', 'episodic', 'task'), content_text (text content summary), importance_score (0-1 floating-point number, initial importance), created_at, last_accessed_at, access_count, source_session_id (source session ID), and is_active (validity status). Semantic vectors use 768 or 1536-dimensional floating-point arrays, generated from the content text through an embedding model. To optimize retrieval performance, the module creates database indexes for global_user_id and memory_type, creates HNSW or IVF indexes for the vector library, and supports vector partitioning by user ID to avoid cross-user retrieval interference.

[0193] For example, the hybrid storage architecture described above is shown in Table 2:

[0194] Table 2 Hybrid Storage Architecture

[0195] memory_id VARCHAR(64), primary key Unique identifier for memory entries global_user_id VARCHAR(64) Global user ID memory_type VARCHAR(32) The memory type enumeration values ​​include "user_preference" (user preference declaration), "background_info" (background information), "task_context" (task context), "knowledge_fact" (knowledge fact), and "interaction_pattern" (interaction pattern). content_text TEXT The text content to be remembered (after summarization) importance_score FLOAT Importance score, ranging from 0.0 to 1.0. source_session_id VARCHAR(64) Source Session ID access_count INTEGER Number of times the search was hit last_accessed_at DATETIME The time of the most recent search hit created_at DATETIME Creation time vector_index_id VARCHAR(64) Corresponding vector record ID in the vector database

[0196] In another exemplary embodiment, the memory writing submodule filters candidate content by combining initial screening with rule engine-assisted judgment.

[0197] In this embodiment, the memory writing submodule filters candidate content by combining rule engine initial screening with model-assisted judgment. After the content that passes the screening is scored for importance and compressed into a summary, the structured metadata and semantic vectors are stored in a relational database and a vector database, respectively, to achieve selective writing of memory with long-term value.

[0198] Specifically, the above screening and extraction process includes the following steps:

[0199] Step 1: Initial screening by the rule engine;

[0200] In this step, candidate content can be initially categorized using a predefined rule engine as follows:

[0201] Explicit preference declaration rules: Match user input containing directive phrases such as "Please do this again," "Please always," "I hope you do this," and "Please remember me."

[0202] Background information declaration rules: Match user input containing self-introduction phrases such as "I am...", "My profession is...", "I work at...", "I use...", etc.

[0203] Continuous task rules: Match expressions that include "This project...", "We are working on...", "Last time we discussed...", etc., which involve the continuation of tasks across sessions;

[0204] Negation exclusion rule: Exclude explicit temporary or one-time content, such as immediate questions and answers like "How's the weather today?" or "Can you calculate 123 × 456 for me?"

[0205] Step 2: Use the model to make an auxiliary judgment;

[0206] In this step, for candidate content that the rule engine cannot clearly classify (i.e., ambiguous content that does not match either the positive rule or the exclusion rule), it is sent to the large language model for auxiliary judgment. The candidate text is provided to the model and it is asked to answer the following: (a) Does the content have cross-session reuse value? (b) If so, what type of memory does it belong to? The model returns a binary classification result (keep / discard) and a memory type label.

[0207] Step 3: Assess the importance of the shortlisted candidates.

[0208] In this step, the importance of the candidate content that passes the initial screening can be scored (with a value range of 0.0 to 1.0) as follows:

[0209] The base weights are determined based on the memory type, including: user preference statement (0.9), background information (0.8), task context (0.7), knowledge facts (0.5), and interaction pattern (0.4). The base weights are multiplied by the content clarity coefficient (the confidence level returned by the model or the accuracy of rule matching) to obtain the final importance score.

[0210] Step 4: Perform digest compression;

[0211] In this step, the candidate content that has passed the screening needs to be summarized. Specifically, if the content is a short sentence (no more than 100 words), the original text is directly retained as the memory text; if the content is long (more than 100 words), the large language model is called to simplify it into a core expression of no more than 100 words, while retaining key entities, intents and constraint information.

[0212] Step 5: Write the processed memory entries into storage.

[0213] In this step, the processed memory entries are written to both a relational database and a vector database, achieving collaborative storage of structured metadata and semantic vectors. Specifically, the summarized memory text, memory type, importance score, source session ID, creation time, and other structured metadata are written to the memory entry table in the relational database. Each memory uses a globally unique identifier as its primary key and is associated with its corresponding global user ID. Simultaneously, a text embedding model is invoked to convert the memory text into semantic vectors of a specified dimension, which are then written to the vector database. The index ID returned by the vector database is then populated back into the corresponding record field in the relational database, ensuring a reliable bidirectional association between the two types of storage and supporting efficient retrieval in the future.

[0214] In summary, the memory writing submodule employs a two-layer screening mechanism of "rule engine initial screening + model-assisted judgment" to accurately identify historical dialogue content. Specifically, it rapidly filters a large amount of temporary and one-off content through predefined positive rules such as explicit preference declarations, background information declarations, and continuous tasks, as well as negative exclusion rules. Then, ambiguous content that cannot be clearly categorized by the rules is handed over to a large language model for secondary judgment, effectively balancing screening efficiency and judgment accuracy. For candidate content that passes the screening, differentiated weights are assigned based on memory type, and importance scores are calculated based on content clarity, ensuring that high-value memories receive higher priority. Simultaneously, a summary compression mechanism simplifies long texts to core expressions of no more than 100 words, preserving key entities, intents, and constraints while controlling the storage and retrieval overhead of individual memories. Finally, structured metadata is written to a relational database, and semantic vectors are written to a vector database, forming a dual-database collaborative storage architecture. This module enables selective writing of long-term memories, avoiding the pollution of the memory bank by a large amount of redundant and temporary information, which helps improve the purity and quality of the memory bank, laying a solid foundation for subsequent accurate retrieval and efficient injection.

[0215] In another exemplary embodiment, the memory retrieval submodule dynamically selects the most relevant memory injection model input by weighting and sorting based on semantic similarity, importance, and time decay.

[0216] In this embodiment, during a new round of dialogue, a query vector is constructed based on the current user input. A similarity search is performed in the long-term memory, and several memories most relevant to the current question are selected. The search process specifically includes the following steps:

[0217] Step 1: Generate query vector. Take the text input by the current user and call the same text embedding model as when it was written to memory to generate a query semantic vector with the same dimensions. ;

[0218] Step 2: Perform similarity retrieval on the query vector;

[0219] In this step, in the vector database, an approximate nearest neighbor (ANN) search is performed on all memory vectors under the global user ID. Cosine similarity is used as the similarity metric to calculate the semantic similarity between the query vector and each memory vector.

[0220] Step 3: Re-rank the retrieved Top-K candidate memories according to their comprehensive relevance scores;

[0221] In this step, the overall relevance score is calculated using the following formula:

[0222]

[0223] in, This represents semantic similarity, with a value range of [0,1]. This indicates the importance score of the memory item, with a value range of [0,1]. The time decay factor is represented by the following formula: ,in, This represents the difference in days between the current time and the time when this memory was last accessed. This represents the attenuation coefficient, with a default value of 0.01. , and This represents the weighting coefficient, and it must satisfy... .

[0224] Step 4: Extract the reordered memories.

[0225] In this step, after sorting by comprehensive relevance score from high to low, the top-scoring candidates are selected. Five memories (e.g., a default value of 5) are used as long-term memories to be injected into the model input. A minimum score threshold is also set (e.g., a default value of 0.3); memories below this threshold are not selected, even if they are within the ranking. For each selected memory entry, its access_count is incremented by 1, and last_accessed_at is updated to the current time.

[0226] In another exemplary embodiment, the memory aging and compression submodule archives and deletes low-value memories and merges and compresses similar memories through comprehensive weight calculation.

[0227] In this embodiment, the memory aging and compression submodule maintains the long-term memory bank by periodically calculating the comprehensive weight of memory entries, and controls the memory size and improves memory quality through operations such as aging, archiving, deletion and merging compression, thereby ensuring retrieval efficiency.

[0228] Specifically, this submodule first performs a comprehensive weight calculation, which includes: executing an aging process task every fixed period (default 7 days), traversing all memory entries for the user, and calculating the comprehensive weight of each memory. The weight is calculated as follows:

[0229]

[0230] in, This indicates the importance score of the memory item, with a value range of [0,1]. This indicates the cumulative number of times the memory entry has been retrieved. This represents the maximum number of hits in the current user's memory, used for normalization. Indicates the time decay factor; , , This represents the weighting coefficient.

[0231] Secondly, based on the comprehensive weight calculation results, this submodule performs the following hierarchical processing: For Memory records below the archiving threshold (default 0.1) are moved from the active memory table to the archive table. Archived memories retain their data but are no longer used for subsequent retrieval. Memory records that have not been actively retrieved by the user after a certain period (e.g., 90 days) are physically deleted.

[0232] Finally, similar memory entries are merged and compressed. During the aging process, similarity detection and merging are performed on memory entries of the same type under the same user: First, the cosine similarity of the semantic vectors of each pair of memory entries is calculated. If the cosine similarity of the semantic vectors of two memories exceeds 0.85, they are judged to be highly similar in content. The text content of these two memories is concatenated and then the large language model is called to perform a merged summary, generating a new memory entry to replace the original two. The importance of the new memory is taken as the larger value of the two, and the access_count is the sum of the two.

[0233] In summary, the memory aging and compression submodule achieves dynamic maintenance and continuous optimization of the long-term memory through periodic comprehensive weight calculation and hierarchical processing mechanisms. This submodule comprehensively considers three dimensions: memory importance, access frequency, and time decay. It archives or even physically deletes low-weight memories, effectively preventing the memory from expanding indefinitely and ensuring that the storage size remains within a controllable range. Simultaneously, it merges and compresses semantically similar memories, generating concise summary entries through a large language model to replace redundant records, thereby improving the compactness and information density of the memory. These mechanisms not only ensure the response efficiency and recall quality of vector retrieval, avoiding interference from low-value or redundant memories in model inference, but also meet data privacy and compliance requirements through a clear forgetting path, providing institutionalized technical support for the lifecycle management of user data.

[0234] In another exemplary embodiment, please refer to Figure 1 The dialogue system also includes a dialogue management module 500, which is responsible for short-term context and state management of individual sessions.

[0235] In this embodiment, the dialogue management module includes a conversation context management submodule, a dialogue state management submodule, and a dialogue summary submodule. The conversation context management submodule is the foundational layer of the dialogue management module, responsible for maintaining the original user input and model response message sequences, and providing the original data source for the other two submodules. The dialogue state management submodule is built on top of the context management submodule, responsible for extracting high-level semantic information such as dialogue goals and task progress and storing it in the form of structured key-value pairs, thereby realizing the abstract understanding and tracking of the conversation process. The dialogue summary submodule is responsible for generating a phase summary based on the context content when the dialogue rounds reach a threshold. This summary is used to fill back into the context as background replacement after removing early messages in the sliding window, and is also passed to the long-term memory management module as candidate content, realizing the deposition from short-term memory to long-term memory.

[0236] Specifically, the conversation context management submodule is responsible for maintaining short-term context information for individual conversations, providing a continuous historical background for each round of dialogue. The system maintains an ordered message list for each active conversation, storing user input and model responses in chronological order. The maximum length of the list is preset to the most recent N rounds of question-and-answer (default N=10, meaning the most recent 10 rounds of question-and-answer, totaling 20 messages). As new messages are continuously added during the conversation, and the number of messages exceeds the limit, the system automatically triggers a sliding window mechanism to remove the earliest question-and-answer record, ensuring the context window remains within a controllable length. Before being removed, the conversation summary submodule determines whether a phase summary needs to be generated or whether content with long-term value needs to be selected and written to long-term memory, thus achieving a smooth transition between short-term context and long-term memory. Through this mechanism, this submodule ensures both the economy of model input length and avoids the simple discarding of important early information.

[0237] The dialogue state management submodule records and tracks the target tasks and progress information during the dialogue process, supporting state awareness and process control in multi-turn interactions. Specifically, this module maintains the following state information: the current dialogue's target intent (e.g., "resolve code errors," "select a design solution"), completed key steps, pending follow-up tasks, and temporary constraints (e.g., "please ignore certain aspects of this dialogue"). This state information is stored in the session context in the form of structured key-value pairs, persisting throughout the session lifecycle, and can be passed to the model at the beginning of each dialogue turn to help the model understand the current stage and unfinished context tasks. This submodule also supports state update, reset, and clearing operations. When the dialogue goal is achieved or the user explicitly switches topics, the relevant states can be cleared or reinitialized to avoid expired states interfering with new dialogues.

[0238] The dialogue summarization submodule is responsible for generating a dialogue summary for this stage when the dialogue reaches a certain length or the session is about to end, and using it as a candidate source for long-term memory or as a supplementary replacement for short-term context. The specific process is as follows: When the dialogue round counter reaches a preset threshold (e.g., every 10 rounds) or a session end signal is detected, the system triggers the summary generation process; all dialogue records in this stage (including user input and model responses) are concatenated into a complete text, the large language model is called, and a structured summary text is generated according to a predefined summary prompt template (e.g., "Please summarize the following dialogue content into a summary of no more than 200 words, including the main topics discussed, the conclusions reached, and the matters to be handled"); the generated summary is passed to the memory writing submodule as candidate content, which determines whether to write it into the long-term memory bank, and is also retained in the session context. When the sliding window mechanism removes early detailed dialogue records, this summary can serve as a replacement for the removed content, providing necessary background reference for subsequent dialogues and avoiding context breaks caused by window truncation.

[0239] In another exemplary embodiment, please continue to see Figure 1 The dialogue system also includes a multi-model access gateway module 600, which is used to uniformly manage the calls to multiple large models.

[0240] In this embodiment, the multi-model access gateway module includes a model routing submodule, a model adaptation submodule, a Prompt construction submodule, and a security and filtering submodule. These four submodules form a pipeline structure from decision-making to execution and from construction to protection, according to the order of request processing. The model routing submodule is at the entry layer, determining the target model to be invoked for this request based on factors such as business scenario, model performance, and cost strategy. Subsequently, the model adaptation submodule takes over, uniformly converting user questions, session context, activation preferences, and retrieved long-term memory into the input format required by the target model. During this process, the Prompt construction submodule, as the basic support for adaptation, is responsible for organizing activation preferences and long-term memory into an abstract prompt structure that can be reused across models according to a predetermined template for the adaptation submodule to call. The security and filtering submodule spans or surrounds the above process, filtering and truncating sensitive information (such as personal identification information, financial information, communication privacy information, authentication credentials, biometric information, and corporate confidential information) before the request is sent, ensuring that the data transmitted to external models complies with privacy and security specifications.

[0241] In another exemplary embodiment, please continue to see Figure 1 The dialogue system also includes a storage and caching module 700, which is responsible for centrally storing data such as identity mapping, user preferences, and long-term memory, and reducing database access by caching hot user information, thereby improving system response efficiency.

[0242] In this embodiment, the storage and caching module includes an identity database, a preference database, a long-term memory database, and a caching submodule. The identity database, preference database, and long-term memory database serve as the underlying persistent storage units, responsible for storing the mapping relationship between platform users and global user IDs, storing user preferences and overlay configuration information, and storing the structured data and vector indexes of memory entries, respectively. The caching submodule sits above the persistent storage, serving as a high-speed access layer. It is specifically used to cache the preference data and frequently used memory entries of frequently accessed users. When a dialogue request is received, it prioritizes reading from the cache, only querying the corresponding underlying database if the cache misses, and synchronously writing the query results back to the cache for subsequent use. By adopting a layered structure of "persistent storage + hotspot caching," the storage and caching module ensures both the persistence and reliability of data and clear categorization, while reducing the direct access pressure on the database, thereby improving the overall response efficiency of the system.

[0243] In another exemplary embodiment, please see further details. Figure 1 The dialogue system also includes a monitoring and analysis module 800, which is used to collect information such as call logs, performance indicators, and memory hits to support subsequent optimization of preference inference strategies and memory strategies.

[0244] In this embodiment, the monitoring and analysis module is responsible for data collection and metric aggregation throughout the entire process, providing data-driven decision-making basis for strategy optimization. Throughout the complete lifecycle of each dialogue request, this module records key call information in the form of structured logs, including but not limited to: the request source platform, the target model for routing, the synthesis result of effective preferences, the list of long-term memory entries hit by the retrieval and their comprehensive relevance scores, the actual number of rounds in the short-term context, the truncation status of security filtering triggers, and the first-word time and total time of the model response. Simultaneously, this module aggregates and maintains multi-dimensional performance metrics, such as the average response latency of each model, token consumption trends, the hit rate and access frequency distribution of long-term memory, and the effective proportion of user preference coverage configurations. Furthermore, the module focuses on tracking memory recall effects, recording the actual adoption of Top-N memories by the model in each retrieval (indirectly judged by analyzing whether the model's response references the memory content), providing empirical evidence for adjusting the weight coefficients (α, β, γ) and minimum score threshold in the comprehensive relevance score formula. The collected data supports real-time monitoring and alarms (such as abnormally high latency, frequent truncation, etc.) and also generates offline analysis reports on a regular basis. This enables maintenance personnel to iteratively optimize preference inference rules, memory filtering strategies, aging and compression parameters, etc., forming a closed loop of "collection-analysis-tuning".

[0245] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A cross-platform personalized dialogue system, characterized in that, The system includes: The multi-platform access module serves as the system's front-end entry point, used to establish network communication with various front-ends and receive heterogeneous requests from users. The platform adaptation module is used to bidirectionally convert heterogeneous requests received by the multi-platform access module into message formats and the unified internal structure of the system, generating standardized requests. The unified user identity management module is used to map, bind, and manage the lifecycle of user accounts across platforms based on standardized requests and global user IDs. The User Preferences and Long-Term Memory Management module is used to centrally manage user preferences and long-term memory information.

2. The system according to claim 1, characterized in that, The multi-platform access module adopts a protocol adaptation layer architecture, using differentiated communication protocols and connection management modes for different front-end types.

3. The system according to claim 1, characterized in that, The platform adaptation module adopts a bidirectional conversion architecture to achieve bidirectional conversion between heterogeneous platform messages and the unified internal structure of the system.

4. The system according to claim 3, characterized in that, The platform adaptation module includes: The message parsing submodule, located in the uplink, is used to uniformly convert heterogeneous raw messages from different platforms into a standardized request structure. The rendering output submodule, located in the downlink, is used to convert the unified response results into a message format that can be recognized and displayed by various target platforms.

5. The system according to claim 1, characterized in that, The unified user identity management module includes: The identity mapping submodule, as the underlying foundation, is responsible for the mapping relationship between external user IDs and global user IDs and generates an identity mapping table. The Login and Binding submodule, located on the Identity Mapping submodule, is used to trigger and change associated records in the Identity Mapping table through process controls such as active binding, automatic matching, and preference merging. The security control submodule is used to encrypt and store the mapping data in the identity mapping submodule, control access permissions, and audit operations. It is also used to perform security verification and log recording for key operations in the login and binding submodule.

6. The system according to claim 5, characterized in that, The login and binding submodule includes active binding mode and automatic matching mode.

7. The system according to claim 5, characterized in that, The security control submodule uses the AES-256-GCM algorithm to encrypt and store sensitive fields in the identity mapping table.

8. The system according to claim 1, characterized in that, The user preference and long-term memory management module includes: The user preference storage submodule serves as the basic data layer, used to centrally store users' global preference settings with the global user ID as the primary key. The platform / model preference coverage submodule serves as the basic data layer, used to record field-level preference coverage configurations for specific platforms or specific large models. The preference parsing and synthesis submodule, as the upper-level logic aggregation point, is used to dynamically read data from the user preference storage submodule and the platform / model preference overlay submodule on each request to generate complete preferences for the current dialogue scenario; The long-term memory storage submodule serves as the persistence center for memory data, storing long-term memory entries extracted from historical dialogues and their semantic vectors. The memory writing submodule is used to filter out content with long-term value during the dialogue and write it into the memory bank; The memory retrieval submodule is used to retrieve the memory most relevant to the current question in a new round of dialogue and select the memory most relevant to the current dialogue. The memory aging and compression submodule, as a background maintenance task, is used to periodically calculate the comprehensive weight of memory entries, archive or delete low-weight memories, and merge and compress memories with highly similar content.

9. The system according to claim 1, characterized in that, The dialogue system also includes a dialogue management module, which is responsible for short-term context and state management of individual sessions.

10. The system according to claim 1, characterized in that, The dialogue system also includes a multi-model access gateway module, which is used to uniformly manage the calls to multiple large models.

Images