Tag data management method and apparatus based on multi-tenant environment

Abstract

The one or more embodiments of the specification provide a label data management method and device based on a multi-tenant environment, which comprises: a platform receiving an information query request sent by a first intelligent agent, analyzing user information of a target user carried therein, and determining an accessible label set thereof; then searching a label database according to the user information, obtaining label information corresponding to the accessible label of the user, the label information being generated based on historical dialogue data of a second intelligent agent and the target user; and finally returning the accessible label and the corresponding label information to the first intelligent agent to support the first intelligent agent to generate personalized dialogue content.

Description

Technical Field

[0001] This specification relates to the field of computer software technology, and more particularly to a tag data management method and apparatus based on a multi-tenant environment. Background Technology

[0002] In the process of applying large language model intelligent agents in vertical industries, most existing user memory solutions have the ability to store dialogue content summaries and interaction history information. Based on a single user's past interaction records, they can provide personalized responses and service support for the user's subsequent intelligent agent dialogue interactions.

[0003] However, the memory storage mechanisms in related technologies are all independent, isolated application-private storage architectures, which can only access the historical dialogue data of the corresponding application itself to serve subsequent interaction scenarios of users within that application. The application boundary is strictly limited to serving the user group of the application itself, and the applicable dimensions and usage scenarios of the memory data are significantly limited. Summary of the Invention

[0004] This specification provides one or more embodiments of a tag data management method and apparatus based on a multi-tenant environment to solve the technical problems that user information cannot be reused across merchants and that new merchants cannot provide personalized services.

[0005] In a first aspect, one or more embodiments of this specification provide a tag data management method based on a multi-tenant environment, comprising: upon receiving an information query request sent by a first intelligent agent, determining an accessible tag corresponding to the first intelligent agent, wherein the information query request includes user information of a target user; obtaining tag information corresponding to the accessible tag from a tag database based on the user information, wherein the tag information is generated based on dialogue data between a second intelligent agent and the target user; and sending the accessible tag and tag information to the first intelligent agent so that the first intelligent agent can generate dialogue content with the target user based on the accessible tag and tag information.

[0006] In one possible implementation, after sending the accessible tag and tag information to the first agent, the method further includes: acquiring the dialogue data to be processed sent by the first agent and determining the accessible tag corresponding to the first agent; extracting tag information corresponding to the accessible tag from the dialogue data to be processed based on the accessible tag; binding the accessible tag and tag information into tag data and storing the tag data in a tag database.

[0007] In one possible implementation, extracting tag information corresponding to the accessible tags from the dialogue data to be processed based on the accessible tags includes: performing feature extraction on the dialogue data to be processed based on the accessible tags to obtain a value vector, wherein the value vector is used to indicate whether the dialogue data to be processed contains information related to the accessible tags; and extracting tag information from the dialogue data to be processed based on a preset extraction rule corresponding to the accessible tags when the value vector indicates that the dialogue data to be processed contains information related to the accessible tags.

[0008] In one possible implementation, before extracting tag information from the dialogue data to be processed based on the preset extraction rules corresponding to the accessible tags, the method further includes: upon receiving a tag addition request sent by a tenant client, determining the tag to be added carried in the tag addition request and the preset extraction rules corresponding to the tag to be added, wherein the tenant client is used to configure the first intelligent agent; determining the tag to be added as an accessible tag; and extracting tag information from the dialogue data to be processed based on the preset extraction rules corresponding to the accessible tags, including: calling a large language model to extract tag information from the dialogue data to be processed based on the preset extraction rules.

[0009] In one possible implementation, storing tag data in a tag database includes: identifying the tag data as short-term tag data and storing it in a short-term tag database, wherein the tag database includes a short-term tag database and a long-term tag database; deleting the short-term tag data if its storage time exceeds a preset time; and processing the short-term tag data in the short-term tag database into long-term tag data if it meets preset transfer conditions, and storing the long-term tag data in the long-term tag database, wherein the storage time of the long-term tag data is greater than the storage time of the short-term tag data.

[0010] In one possible implementation, processing short-term tag data into long-term tag data includes: obtaining standard tag definitions from a long-term tag database, wherein the standard tag definitions include at least one standard tag and its corresponding mapping rule; determining the target mapping rule and target tag corresponding to the short-term tag data; converting the tag information contained in the short-term tag data into target tag information according to the target mapping rule; and binding the target tag and target tag information into long-term tag data.

[0011] In one possible implementation, if the short-term tag data in the short-term tag database meets the preset transfer conditions, the short-term tag data is processed into long-term tag data, including at least one of the following: if the number of times the short-term tag data is stored is greater than a preset number, the short-term tag data is processed into long-term tag data, wherein the preset number of positive short-term tag data is greater than the preset number of negative short-term tag data; if the confidence level of the short-term tag data is greater than a confidence level threshold, the short-term tag data is processed into long-term tag data, wherein the confidence level is used to indicate the confidence level of the tag information included in the short-term tag data during the extraction stage; if a long-term storage instruction is identified in the dialogue data to be processed, the short-term tag data is processed into long-term tag data.

[0012] In one possible implementation, after storing the tag data in a tag database, the process includes: upon receiving a tag data viewing request from a user client, determining the user information to be verified carried in the tag data viewing request, wherein the user client is used to support dialogue between the target user and a first intelligent agent and a second intelligent agent; retrieving the tag data to be viewed from the tag database that matches the user information to be verified, and returning the tag data to be viewed to the user client.

[0013] In one possible implementation, before determining the accessibility tag corresponding to the first agent, the process includes: upon receiving configuration information sent by the tenant client, determining at least one request authorization tag carried in the configuration information as an accessibility tag based on the service type of the first agent, wherein the tenant client is used by the tenant to configure the first agent; generating a tag access code based on the tenant identifier of the tenant client, the agent identifier of the first agent, and the accessibility tag; and determining the accessibility tag corresponding to the first agent, including: determining the accessibility tag corresponding to the first agent based on the tag access code.

[0014] In one possible implementation, a tag access code is generated based on the tenant identifier of the tenant client, the agent identifier of the first agent, and the accessibility tag, including at least one of the following: concatenating the tenant identifier, the agent identifier, and the accessibility tag to obtain a tag access code; concatenating the tenant identifier, the agent identifier, and the accessibility tag and then compressing them according to a preset compression method to obtain a tag access code, wherein the number of bits in the tag access code is fixed; concatenating the tenant identifier, the agent identifier, and the accessibility tag and then encrypting them according to a preset encryption method to obtain encrypted information; and forming a tag access code based on the encrypted information, the tenant identifier, the agent identifier, and the accessibility tag.

[0015] Secondly, one or more embodiments of this specification provide a tag data management device based on a multi-tenant environment, comprising: a tag determination module, configured to determine an accessible tag corresponding to a first intelligent agent upon receiving an information query request sent by a first intelligent agent, wherein the information query request includes user information of a target user; an information acquisition module, configured to acquire tag information corresponding to the accessible tag from a tag database based on the user information, wherein the tag information is generated based on dialogue data between a second intelligent agent and a target user; and a sending module, configured to send the accessible tag and tag information to the first intelligent agent, so that the first intelligent agent can generate dialogue content with the target user based on the accessible tag and tag information.

[0016] In one possible implementation, the apparatus further includes: an information extraction module, configured to acquire the dialogue data to be processed sent by the first intelligent agent and determine the accessible tag corresponding to the first intelligent agent; extract tag information corresponding to the accessible tag from the dialogue data to be processed based on the accessible tag; bind the accessible tag and the tag information into tag data, and store the tag data in a tag database.

[0017] In one possible implementation, the information extraction module is further configured to: extract features from the dialogue data to be processed based on the accessible tags to obtain a value vector, wherein the value vector is used to indicate whether the dialogue data to be processed contains information related to the accessible tags; and extract tag information from the dialogue data to be processed based on the preset extraction rules corresponding to the accessible tags when the value vector indicates that the dialogue data to be processed contains information related to the accessible tags.

[0018] In one possible implementation, the information extraction module is further configured to: upon receiving a tag addition request sent by a tenant client, determine the tag to be added carried in the tag addition request and the preset extraction rule corresponding to the tag to be added, wherein the tenant client is used to configure the first intelligent agent; determine the tag to be added as an accessible tag; and call the large language model to extract tag information from the dialogue data to be processed based on the preset extraction rule.

[0019] In one possible implementation, the information extraction module is further configured to: identify the tag data as short-term tag data and store it in a short-term tag database, wherein the tag database includes a short-term tag database and a long-term tag database; if the storage time of the short-term tag data exceeds a preset time, delete the short-term tag data; if the short-term tag data in the short-term tag database meets preset transfer conditions, process the short-term tag data into long-term tag data and store the long-term tag data in the long-term tag database, wherein the storage time of the long-term tag data is greater than the storage time of the short-term tag data.

[0020] In one possible implementation, the information extraction module is further configured to: obtain standard tag definitions from the long-term tag database, wherein the standard tag definitions include at least one standard tag and its corresponding mapping rule; determine the target mapping rule and target tag corresponding to the short-term tag data; convert the tag information contained in the short-term tag data into target tag information according to the target mapping rule; and bind the target tag and target tag information into long-term tag data.

[0021] In one possible implementation, the information extraction module is further configured to: process short-term tag data into long-term tag data when the number of times short-term tag data is stored is greater than a preset number, wherein the preset number of times positive short-term tag data corresponds to is greater than the preset number of times negative short-term tag data corresponds to; process short-term tag data into long-term tag data when the confidence level of short-term tag data is greater than a confidence level threshold, wherein the confidence level is used to indicate the confidence level of the tag information included in the short-term tag data during the extraction stage; and process short-term tag data into long-term tag data when a long-term storage instruction is identified in the dialogue data to be processed.

[0022] In one possible implementation, the information extraction module is further configured to: upon receiving a tag data viewing request sent by a user client, determine the user information to be verified carried in the tag data viewing request, wherein the user client is used to support dialogue between the target user and the first and second intelligent agents; retrieve the tag data to be viewed that matches the user information to be verified from the tag database, and return the tag data to be viewed to the user client.

[0023] In one possible implementation, the tag determination module is further configured to: upon receiving configuration information sent by the tenant client, determine at least one request authorization tag carried in the configuration information as an accessible tag based on the service type of the first intelligent agent, wherein the tenant client is used to configure the first intelligent agent; generate a tag access code based on the tenant identifier of the tenant client, the intelligent agent identifier of the first intelligent agent, and the accessible tag; and determine the accessible tag corresponding to the first intelligent agent based on the tag access code.

[0024] In one possible implementation, the tag determination module is further configured to: concatenate the tenant identifier, agent identifier, and accessible tag to obtain a tag access code; concatenate the tenant identifier, agent identifier, and accessible tag and compress them according to a preset compression method to obtain a tag access code, wherein the number of bits in the tag access code is fixed; concatenate the tenant identifier, agent identifier, and accessible tag and encrypt them according to a preset encryption method to obtain encrypted information; and compose a tag access code based on the encrypted information, the tenant identifier, agent identifier, and accessible tag.

[0025] Thirdly, one or more embodiments of this specification also provide an electronic device, which includes a memory and a processor; the memory is used to store a computer program product; the processor is used to execute the computer program product stored in the memory, and when the computer program product is executed, it implements the method of the first or second aspect described above.

[0026] Fourthly, one or more embodiments of this specification also provide a computer-readable storage medium storing computer program instructions that, when executed, implement the methods of the first or second aspect described above.

[0027] Based on the implementation methods provided in the above aspects, one or more embodiments of this specification can be further combined to provide more implementation methods.

[0028] Through the above method, the platform assigns a tag access code to each merchant's (tenant's) intelligent agent, containing a merchant identifier (tenant identifier), an intelligent agent identifier, and a set of tags. When the first intelligent agent initiates an information query request, the platform accurately determines the range of tags it can access based on this tag access code, rather than returning the full user profile, thus achieving data access control under the principle of least privilege. Furthermore, based on the target user information in the request, the platform retrieves corresponding tag information from a unified multi-tenant tag database. This information is formed by asynchronously extracting and normalizing historical dialogue data between the second intelligent agent and the target user. Finally, the platform returns the tags and corresponding information within its authorized range to the first intelligent agent, enabling the first intelligent agent to obtain the user's basic profile upon first service, effectively solving the cold start problem when new merchants join. Simultaneously, since the tag information of the same user can be reused by intelligent agents of different merchants within the authorized range, data redundancy and duplicate collection caused by each merchant independently building its memory system are avoided. This achieves shared collaboration and efficient transfer of cross-merchant tag assets while ensuring user privacy and security. Attached Figure Description

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

[0030] Figure 1 A system schematic diagram illustrating a tag data management method based on a multi-tenant environment, provided for one or more embodiments of this specification; Figure 2A flowchart illustrating a tag data management method based on a multi-tenant environment, provided for one or more embodiments of this specification; Figure 3 A flowchart illustrating another tag data management method based on a multi-tenant environment provided in one or more embodiments of this specification; Figure 4 A schematic diagram of a tag database for a tag data management method based on a multi-tenant environment provided in one or more embodiments of this specification; Figure 5 A schematic diagram of a user client for a tag data management method based on a multi-tenant environment provided in one or more embodiments of this specification; Figure 6 A schematic diagram illustrating a tag data management method based on a multi-tenant environment, provided for one or more embodiments of this specification; Figure 7 A structural block diagram of a tag data management device based on a multi-tenant environment, provided for one or more embodiments of this specification; Figure 8 This is a structural block diagram of an electronic device provided for one or more embodiments of this specification. Detailed Implementation

[0031] The present specification describes one or more embodiments in further detail below with reference to the accompanying drawings and examples. Through these descriptions, the features and advantages of one or more embodiments of the present specification will become clearer and more apparent.

[0032] The term “exemplary” as used herein means “serving as an example, embodiment, or illustration.” Any embodiment illustrated herein as “exemplary” is not necessarily to be construed as superior to or better than other embodiments. Although various aspects of embodiments are shown in the accompanying drawings, the drawings are not necessarily drawn to scale unless specifically indicated otherwise.

[0033] Furthermore, the technical features described below in one or more embodiments of this specification may be combined with each other as long as they do not conflict with each other.

[0034] It should be noted that the acquisition and processing of user data involved in the methods described in this manual strictly adhere to the principles of legality, legitimacy, and necessity, and the entire process has been authorized and consented to by the user. Before collecting user dialogue data, the platform has informed users of the purpose, scope, and method of data use through a clear and easy-to-understand authorization agreement, allowing users to choose whether to authorize and the specific scope of authorization. Furthermore, this solution employs a field-level permission control mechanism, allowing users to view, modify, or revoke access authorization for specific data from specific merchants or applications at any time, ensuring users have full knowledge and control over their own data. In addition, the platform strictly adheres to the principle of minimum necessity in data collection, extracting only information subscribed to by merchants and authorized by users, and does not involve user privacy data unrelated to the service, comprehensively protecting user data security and privacy rights.

[0035] According to one or more embodiments of this specification, a tag data management method based on a multi-tenant environment is provided. As an optional implementation, the above-described tag data management method based on a multi-tenant environment can be applied, but is not limited to, to applications such as... Figure 1 The illustrated tag data management system is based on a multi-tenant environment. This multi-tenant tag data management system may include, but is not limited to, terminal device 102, network 110, platform server 112, tenant server one 118, and tenant server two 120. Terminal device 102 runs a target client. For example... Figure 1 In the illustrated embodiment, the target client is a client capable of interacting with a target user to generate dialogue. The terminal device 102 includes a memory 104, a processor 106, and a display 108. The display 108 can be used to display text information, image information, etc., and also provides a human-computer interaction interface to receive human-computer interaction operations such as selecting objects in the object interaction platform and touching different controls. The processor 106 is used to generate interaction instructions in response to the aforementioned human-computer interaction operations and send the interaction instructions to the tenant server 118 to interact with the intelligent agent in the tenant server 118 to generate dialogue. The memory 104 is used to store dialogue data.

[0036] Tenant server 118 can be a merchant's own or rented cloud computing resource used to deploy intelligent agent service programs. This can be understood as a merchant becoming a tenant of the platform after joining. The tenant can use the platform's infrastructure, but the intelligent agent may be deployed on its own server. The intelligent agent is an intelligent dialogue system running on the tenant server. It can receive user input, call the Large Language Model (LLM) to generate responses, and communicate with platform server 112 via network 110 to obtain tag information for personalized services, or send dialogue data to platform server 112. Tenant server 120 works similarly to tenant server 118 and will not be explained again. It is important to emphasize that tenant server 118 and tenant server 120 can be the same tenant server or different tenant servers.

[0037] In addition, the platform server 112 includes a database 114 and a processing engine 116. The processing engine 116 is used to perform storage or retrieval operations on the database 114. Specifically, the processing engine 116 retrieves tag information from the database 114. The platform server is a multi-tenant platform, meaning that multiple merchants (third-party organizations) share the same set of platform memory service infrastructure, but the data is isolated from each other and configured independently. Tenants are merchants that have joined the platform, such as recruitment platforms, training institutions, insurance companies, etc. The platform's unified memory storage, extraction, processing, and query infrastructure is shared by multiple tenants, but each tenant is assigned data access permissions, and tenants do not access each other beyond their permissions, realizing an architecture where multiple merchants share resources but the data is logically isolated under the same platform.

[0038] According to this embodiment, Figure 1 In this embodiment, a first intelligent agent runs on tenant server 118, and a second intelligent agent runs on tenant server 120. When a target user sends a dialogue request to the first intelligent agent via terminal device 102 to initiate a dialogue with the first intelligent agent, the specific process is as follows: In step S102, the first agent in tenant server 118 sends an information query request to platform server 112 through network 110; In step S104, when the platform server 112 receives the information query request sent by the first intelligent agent, it determines the accessible tag corresponding to the first intelligent agent, wherein the information query request includes the user information of the target user. In step S106, the platform server 112 retrieves the tag information corresponding to the accessible tags from the tag database based on the user information. The tag information is generated based on the dialogue data between the second intelligent agent and the target user. In step S108, platform server 112 sends accessible tags and tag information to the first agent running in tenant server 118, so that the first agent can generate dialogue content with the target user based on the accessible tags and tag information.

[0039] Optionally, in this embodiment, the terminal device 102 can be a terminal device configured with a target client, which may include, but is not limited to, at least one of the following: mobile phone (such as Android phone, iOS phone, etc.), laptop computer, tablet computer, PDA, MID (Mobile Internet Devices), PAD, desktop computer, smart TV, etc. The target client may be a social client, e-commerce client, browser client, etc., that supports providing tag data management tasks based on a multi-tenant environment. The server may be a single server, a server cluster composed of multiple servers, or a cloud server. The above is only an example, and no limitation is made in this embodiment. The network may include, but is not limited to, wired networks and wireless networks, wherein the wired network includes: local area network, metropolitan area network, and wide area network, and the wireless network includes: Bluetooth, WIFI, and other networks that enable wireless communication. In the process of utilizing network communication, the communication protocol used may be the Model Context Protocol (MCP) to allow the agent to call the data source in the platform server 112 in a standardized manner.

[0040] For ease of understanding, the application scenarios of the technical solutions provided in one or more embodiments of this specification are described below.

[0041] Optionally, in one example, user Zhang is a Java developer with five years of experience who recently expressed interest in switching to the AI ​​field. He has his first conversation with merchant A within the platform ecosystem, revealing his professional background: "I'm a Java developer, and I want to switch to AI, expecting a salary of around 25k, and I'm looking for job opportunities in city A." The platform asynchronously extracts and stores Zhang's tag information, including: Career Direction = Java Development, Switch to Any Direction = AI, Salary Expectation = 25k, Job Location = City A, and stores it in the tag database. Two weeks later, Zhang discovers merchant B's career planning agent on the platform; this is his first contact with the agency. In the traditional model, new merchants cannot access user history profiles, and the agent would need to retrieve Zhang's background information from scratch, resulting in a fragmented experience. However, in this solution, the career planning agent sends an information query request to the platform, carrying Zhang's user information. The platform parses the agent's tag access code, determines its accessible tags as {Career Direction, Switch to Any Direction}, and retrieves the corresponding information from the tag database: Career Direction = Java Development, Switch to Any Direction = AI. The training agent immediately generated a personalized response: "We understand you have a Java background and wish to transition to the AI ​​field. We recommend 'Introduction to Python Machine Learning' and 'Deep Learning Engineer Certification Course,' suitable for students with programming experience." Throughout the process, Merchant B's agent, acting as a new merchant, obtained an accurate profile without requiring repeated user input, solving the cold start problem. Simultaneously, field-level permission isolation ensured the agent could only see "career direction" and "transition to any direction" related to the course recommendations, preventing access to sensitive information such as "salary expectations," thus protecting user privacy and security.

[0042] Optionally, in one example, user Xiao Wang is a senior product manager who has interacted with agents from multiple merchants within the platform ecosystem, accumulating rich tag data: Career direction = Product Manager, Salary expectation = 40k, Job search location = Shanghai, Skills certificate = PMP, Project experience = 10 years, Family status = Married with one child. Xiao Wang views his tag profile on the "My Memory Data" page (user client side). He considers his salary expectation to be sensitive information and does not want training merchants to access it. Therefore, Xiao Wang sends a tag data viewing request through the user client. After verifying his user identity, the platform returns the complete tag data to be viewed. Xiao Wang selects the "Salary Expectation" tag and clicks "Revoke Authorization." The platform immediately closes the cross-merchant sharing permission for that tag. Subsequently, when a training institution's agent queries Xiao Wang's data, the platform parses his tag access code, verifies the accessible tag set, and finds that "Salary Expectation" is no longer within the authorized scope, only returning: Career direction = Product Manager, Skills certificate = PMP, Project experience = 10 years. Simultaneously, when a recruitment platform's agent queries, the platform returns complete information including "Salary Expectation = 40k." By isolating permissions at the field level, users are not passively subjected to sharing across the entire platform, but can precisely control which tags are visible to which merchants, ensuring user privacy and security while enjoying the convenience of personalized services.

[0043] The above use cases are merely examples. Any scenario related to tag data management in a multi-tenant environment can utilize the solutions of one or more embodiments in this specification. This embodiment does not impose any limitations on this.

[0044] The following describes embodiments of the tag data management method based on a multi-tenant environment provided in one or more embodiments of this specification.

[0045] Figure 2 A flowchart illustrating a tag data management method based on a multi-tenant environment, provided for one or more embodiments of this specification; as shown. Figure 2 As shown, this method can be applied to the platform server in the above architecture, and the method may include the following steps: Step S202: Upon receiving an information query request sent by the first intelligent agent, determine the accessible tag corresponding to the first intelligent agent, wherein the information query request includes the user information of the target user; As described in the system architecture section above, the first intelligent agent refers to the AI ​​intelligent agent program deployed on the tenant-side server, providing dialogue services to end users. This intelligent agent can be developed or integrated by third-party merchants and communicates with the platform server through a communication protocol.

[0046] It should be noted that an information query request can be a request sent by the first intelligent agent to the platform server to obtain historical data information of the target user. This request may include core fields such as tenant identifier, intelligent agent identifier, and target user's user information, which are used by the platform to locate the query subject and object. The target user is the end user currently interacting with the first intelligent agent; their user information includes identity credentials such as a user identifier, which the platform uses to retrieve corresponding data from the multi-tenant tag database.

[0047] Accessible tags are a set of user memories that are authorized by the platform and accessible to specific intelligent agents. This set is configured by merchants through a tenant client subscription when they join the platform, or by merchants through a tenant client subscription when they wish to obtain more information, and is encoded in the tag access code after platform review.

[0048] When the platform receives an information query request, it can determine the accessible tag corresponding to the first intelligent agent in various ways. The following examples illustrate possible implementation methods: In one possible implementation, upon receiving an information query request, the platform server extracts the tenant identifier and agent identifier, and queries a local mapping table to obtain a pre-generated tag access code. This access code is constructed by the platform during the merchant onboarding configuration phase, by concatenating or compressing the merchant's subscribed tag set, tenant identifier, and agent identifier, and contains all tag information authorized for the agent's access. After performing integrity and timeliness checks on the access code, the platform decodes it to obtain the set of accessible tags.

[0049] In another possible implementation, after receiving an information query request, the platform server determines the tag access code it carries, and parses the tag access code to obtain the tenant identifier, agent identifier, and accessible tags. If the tenant identifier and agent identifier of the tenant client match the tag access code, the tag access code is decoded to obtain the set of accessible tags.

[0050] In another possible implementation, for high-frequency query scenarios, after the platform server initially parses the tag access code, it writes the mapping relationship between the tenant identifier, agent identifier, and the set of accessible tags into a high-speed cache. When subsequent query requests from the same agent are received, the accessible tags are preferentially read from the cache, reducing redundant decoding overhead and improving query response speed. Cache entries are set with expiration times and automatically expire and are rebuilt after the merchant changes their subscription configuration, ensuring permission consistency.

[0051] The above implementation methods all utilize tag access codes, therefore the following section describes the configuration and generation process of tag access codes.

[0052] In an optional implementation, before determining the accessible tag corresponding to the first intelligent agent, the method includes: upon receiving configuration information sent by the tenant client, determining at least one request authorization tag carried in the configuration information as an accessible tag based on the service type of the first intelligent agent, wherein the tenant client is used by the tenant to configure the first intelligent agent; generating a tag access code based on the tenant identifier of the tenant client, the intelligent agent identifier of the first intelligent agent, and the accessible tag; determining the accessible tag corresponding to the first intelligent agent includes: determining the accessible tag corresponding to the first intelligent agent based on the tag access code.

[0053] As described in the system architecture section above, the tenant client refers to the management software used by merchant operators to configure intelligent agent services, such as a web page or management backend. This client is distinct from the user client for end users and supports merchant onboarding to the platform, subscribing to tags, configuring rules, and viewing data.

[0054] It should be noted that configuration information refers to the data packet sent by the tenant client to the platform server to set the parameters of the intelligent agent service. This data includes the merchant's service type, the list of tags requested for authorization, and extraction rules. The service type refers to the merchant's industry sector or service scope, such as recruitment services, vocational training, or insurance consulting. This type is used by the platform to conduct compliance review and service compatibility verification of the requested authorization tags, ensuring that the tag subscription matches the merchant's actual service scenario. The requested authorization tags refer to the memory dimensions that the merchant requests access to from the platform during the onboarding process; that is, the tag fields they hope to extract and use from user conversations, such as career direction, salary expectations, and skill certificates.

[0055] A tenant identifier is a unique identity assigned by the platform to merchants, used to distinguish the data space and permission boundaries of different merchants in a multi-tenant environment. An agent identifier is a unique identity assigned by the platform to a specific agent application deployed by a merchant. A single merchant may have multiple agent applications; each agent identifier is independent and bound to a different set of accessible tags.

[0056] In an optional implementation, a tag access code is generated based on the tenant identifier of the tenant client, the agent identifier of the first agent, and the accessible tag, including at least one of the following: 1) Concatenate the tenant identifier, agent identifier, and accessible tag to obtain the tag access code; 2) After concatenating the tenant identifier, agent identifier, and accessible tag, the tag access code is obtained by compression according to a preset method. The number of bits in the tag access code is fixed. 3) After concatenating the tenant identifier, agent identifier, and accessibility tag, the encrypted information is obtained according to the preset encryption method; the tag access code is formed based on the encrypted information, tenant identifier, agent identifier, and accessibility tag.

[0057] It should be noted that the concatenation process can combine multiple data fields into a single string according to a predetermined order and format. Fixed delimiters or reserved length fields can be used during concatenation to ensure accurate reconstruction of each component during subsequent parsing. The preset compression method can be a platform-defined data compression algorithm or encoding rule used to reduce the storage size and transmission overhead of the tag access code. Examples include bitmap encoding, hash digests, and dictionary mapping, which can convert data into a fixed-length compressed representation. The preset encryption method can be a platform-defined data encryption or signature algorithm used to protect the integrity and confidentiality of the tag access code. Examples include symmetric encryption, asymmetric encryption, or digital signatures, generating encrypted information to prevent the access code from being tampered with or forged.

[0058] It should be noted that by providing three progressive encoding methods—concatenation, compression, and encryption—the platform can adapt to different application scenarios and security requirements. For example, concatenation is suitable for internal trusted environments, compression is suitable for large-scale, high-concurrency scenarios, and encryption is suitable for externally accessible or untrusted network environments. Specifically: In an optional implementation, the platform concatenates the tenant identifier string, agent identifier string, and list of accessible tags into a single string using separators in a predetermined order, forming a plaintext tag access code. For example, the format is Tenant Identifier|Agent Identifier|Tag A, Tag B, Tag C, with vertical bars separating the parts and commas separating the tag list. This method is simple to implement and requires no additional computational overhead.

[0059] In an optional implementation, the platform first concatenates the tenant identifier, agent identifier, and accessible tags into a raw string using method one, and then processes it using a preset compression algorithm to generate a fixed-length compressed code. The compression method can use bitmap encoding: a tag pool consisting of all available tags is predefined, each tag is assigned a binary bit, the bit corresponding to an accessible tag is set to 1, and the inaccessible bit is set to 0, and finally all bits are compressed into a fixed-length byte sequence.

[0060] In an optional implementation, the platform first concatenates the tenant identifier, agent identifier, and accessible tag into structured plaintext, and then generates encrypted information using a preset encryption method. The encryption method can be a symmetric encryption algorithm, using the platform key to encrypt the plaintext and generate ciphertext; or an asymmetric signature algorithm, using the platform's private key to sign the plaintext and generate a signature value. The final tag access code is composed of encrypted information (ciphertext or signature) and the original plaintext, such as "plaintext|ciphertext" or "plaintext|signature". During platform verification, the plaintext and encrypted information are separated from the access code, and the corresponding key is used to decrypt or verify the signature, confirming that the access code has not been tampered with and its source is trustworthy.

[0061] Through one or more embodiments of this specification, tenant identifiers, agent identifiers, and accessible tags are bound and encoded into tag access codes. This eliminates the need for external database queries for permission verification, reducing query latency. Furthermore, when merchants join the platform, they do not indiscriminately acquire all tag capabilities. Instead, they apply for necessary tags based on their service type, and the platform reviews these applications to form a minimum authorized set, thus protecting user data privacy.

[0062] Step S204: Obtain tag information corresponding to accessible tags from the tag database based on user information, wherein the tag information is generated based on the dialogue data between the second intelligent agent and the target user; It should be noted that the tag database refers to the database system on the platform server used to uniformly store user tag information in a multi-tenant environment. This database organizes data according to user information (user identifiers) and contains various tag information accumulated by the same user during interactions with different intelligent agents. Tag information refers to structured memory content extracted from user dialogue data, such as career direction (tag) = Java development (tag information), salary expectation (tag) = 25k (tag information), etc.

[0063] The second agent refers to another agent application that has engaged in historical dialogues with the target user and extracted and generated tag information from them. This agent and the first agent may belong to different tenants, i.e., services deployed by different merchants. Dialogue data refers to the original dialogue text generated during the interaction between the second agent and the target user, or data processed based on the original dialogue text. This data is the raw material for tag information extraction. The dialogue text does not restrict the data format; depending on the dialogue, the data can include text data, image data, or audio and video data, etc., without limitation here.

[0064] There are no restrictions on the query methods in the tag database. For ease of understanding, the following describes possible implementation methods. It should be clear that the specific query methods are not limited to the implementation methods given in the embodiments of the specification.

[0065] In one optional implementation, the platform server locates the target user's data partition in the user master index of the tag database based on the user identifier in the user information. Within that partition, matching tag records are retrieved using accessible tags as query criteria, and the tags and their corresponding tag information are extracted and returned.

[0066] In another optional implementation, after receiving a query request, the platform server checks whether a snapshot of the user's tag information already exists in the cache layer. If the cache is hit and has not expired, the tag information corresponding to the accessible tag is directly retrieved from the cache and returned; if the cache is missed or has expired, the system goes back to the tag database to perform an index query and writes the query result into the cache for subsequent reuse.

[0067] Step S206: Send accessible tags and tag information to the first intelligent agent so that the first intelligent agent can generate dialogue content with the target user based on the accessible tags and tag information.

[0068] The dialogue content refers to the response text generated by the first agent based on the returned accessible tags and tag information, combined with the current dialogue context and the capabilities of a large language model. This response incorporates the user's historical tag information to achieve a personalized and coherent interactive experience.

[0069] It should be noted that there are no restrictions on the method of sending accessible tags and tag information to the first intelligent agent. For ease of understanding, two possible implementation methods are given below.

[0070] In one optional implementation, after the platform server completes the tag information retrieval in step S204, it immediately establishes a response connection with the first intelligent agent via a communication protocol (e.g., the MCP protocol), encapsulates the accessible tag list and corresponding tag information in a structured data format, and synchronously returns it to the first intelligent agent. Upon receiving this, the first intelligent agent injects the tag information into the current dialogue context and invokes a large language model to generate a personalized response that integrates the user profile.

[0071] In another alternative implementation, before returning tag information, the platform server pre-formats the accessible tags and tag information into a context-injection template recognizable by the large language model, such as "User Profile: Career Direction = Java Development; Salary Expectation = 25k". Upon receiving this template text, the first agent directly embeds it into system prompts or the user's context and invokes the large language model to generate a response. This approach simplifies the data processing logic on the agent side, standardizes the use of tag information, lowers the technical barrier for merchant access, and is more adaptable to agents with varying development capabilities in multi-tenant environments.

[0072] Through the above method, the platform assigns a tag access code to each merchant's (tenant's) intelligent agent, containing a merchant identifier (tenant identifier), an intelligent agent identifier, and a set of tags. When the first intelligent agent initiates an information query request, the platform accurately determines the range of tags it can access based on this tag access code, rather than returning the full user profile, thus achieving data access control under the principle of least privilege. Furthermore, based on the target user information in the request, the platform retrieves corresponding tag information from a unified multi-tenant tag database. This information is formed by asynchronously extracting and normalizing historical dialogue data between the second intelligent agent and the target user. Finally, the platform returns the tags and corresponding information within its authorized range to the first intelligent agent, enabling the first intelligent agent to obtain the user's basic profile upon first service, effectively solving the cold start problem when new merchants join. Simultaneously, since the tag information of the same user can be reused by intelligent agents of different merchants within the authorized range, data redundancy and duplicate collection caused by each merchant independently building its memory system are avoided. This achieves shared collaboration and efficient transfer of cross-merchant tag assets while ensuring user privacy and security.

[0073] Steps S202-S206 above describe the process of querying data (tags and corresponding tag information) from the tag database. After returning the data to the first agent, the first agent can generate dialogue content. During or after the dialogue between the first agent and the user, the platform can obtain the dialogue data of the first agent and extract tag information based on the dialogue data to update the tag database. The specific process will be explained below: In an optional implementation, after sending the accessible tag and tag information to the first agent, the method further includes: obtaining the dialogue data to be processed sent by the first agent and determining the accessible tag corresponding to the first agent; extracting the tag information corresponding to the accessible tag from the dialogue data to be processed based on the accessible tag; binding the accessible tag and tag information into tag data and storing the tag data in a tag database.

[0074] The dialogue data to be processed refers to the raw dialogue text generated during the interaction between the first intelligent agent and the target user. This data has not yet been tagged and is in a state of pending analysis; it is the raw material for the platform to generate new tag information.

[0075] Tag data refers to structured data units formed by binding accessible tags with extracted tag information. This unit can contain metadata such as tag fields, tag information, source agent, and generation time, and is the smallest storage record in the tag database.

[0076] It's important to note that the platform not only provides historical memory query services to agents but also extracts valuable information from the current conversation, forming reusable memory assets. By asynchronously acquiring the dialogue data after the first agent's query, the user profile is continuously enriched with the number of interactions, providing a sustainable data foundation for long-term personalized services in a multi-tenant environment.

[0077] The following describes the possible implementation methods for sending the dialogue data to be processed from the first agent to the platform server: Optionally, during the dialogue between the first intelligent agent and the target user, the first intelligent agent reports the dialogue data to the message queue of the platform server in real time. The platform asynchronously pulls the dialogue data to be processed, performs information extraction based on the accessible tags of the intelligent agent, generates tag data, and writes it to the tag database.

[0078] Optionally, the first agent locally caches dialogue data during the conversation and reports it to the platform in batches at preset intervals or at the end of the session. Upon receiving the data, the platform performs batch tag extraction on the dialogue data to be processed, generating multiple tag records and writing them to the database at once. This method reduces the number of network requests and the instantaneous pressure on the platform, making it suitable for scenarios with low dialogue frequency or limited network resources.

[0079] Optionally, when the first agent detects that the dialogue content involves topics related to accessible tags, it immediately reports that segment of dialogue data to the platform. Upon receiving the data, the platform prioritizes high-priority segments, quickly extracting and storing tags, making the newly added memories immediately visible in subsequent queries. This approach shortens the latency from memory generation to availability, making it suitable for service scenarios with high real-time requirements.

[0080] Figure 3 A flowchart illustrating another tag data management method based on a multi-tenant environment provided in one or more embodiments of this specification; as shown. Figure 3 As shown, users can interact with the first intelligent agent (such as a career planning intelligent agent) through terminal devices. The first intelligent agent then interacts with the platform side. The platform side can include two types of components: platform service components and tag components (i.e., tag database). Specifically: S302, the first intelligent agent sends an information query request; The first intelligent agent can send an information query request to the platform through the MCP protocol. The request carries the user information of the target user (such as user identifier, session identifier, etc.), as well as the first intelligent agent's own tenant identifier and intelligent agent identifier.

[0081] S304, The platform service component determines the accessible tag corresponding to the first intelligent agent; The platform uses the tenant identifier and agent identifier carried by the first agent to query the permission mapping table in the tag database and retrieve the tag access code corresponding to that agent. It then parses the tag access code to decode the set of accessible tags that the agent is authorized to access. Finally, it determines the list of tags that the first agent is authorized to access, such as {career direction, salary expectation, job search location}.

[0082] S306, The platform service component obtains tag information from the tag component. The platform service component uses the target user's user information as the search key to query the tag database for that user's tag data. The returned results are filtered by the set of accessible tags, retaining only tags within the authorized scope and their corresponding tag information. Tag information matching accessible tags is retrieved, such as {Career Direction = Java Development, Salary Expectation = 25k}.

[0083] S308, The platform sends accessible tags and tag information to the first intelligent agent; The platform encapsulates the list of accessible tags and their corresponding tag information into a response message and returns it to the first agent via the MCP protocol. Upon receiving the message, the first agent injects the tag information into the dialogue context and invokes a large language model to generate personalized responses that incorporate the user's historical profile.

[0084] S310-S312, the first agent generates and sends the dialogue data to be processed; After the first agent completes a dialogue interaction with the target user, it asynchronously delivers a copy of the dialogue to the platform. The dialogue data to be processed includes raw information such as user input, agent responses, dialogue timestamps, and session identifiers.

[0085] S314, The platform determines that the tag is accessible and extracts the tag information; The platform parses the tag access code of the first intelligent agent to determine its set of accessible tags. Based on the accessible tags, it performs a value judgment on the dialogue data to be processed, identifying whether it contains valid information. For valuable dialogues, it invokes a large language model to perform precise extraction based on preset extraction rules, generating tag information. The extracted tag information, such as {career direction = Java development}, is bound to the accessible tags to form tag data.

[0086] S316, the platform stores the tag data in the tag database; The labeled data is identified as labeled data and written to the label database. The record contains metadata such as label name, label value, source agent identifier, generation timestamp, confidence level, and occurrence count counter.

[0087] Through one or more embodiments in this specification, the platform enables the continuous accumulation and dynamic updating of user memory information in a multi-tenant environment. User profiles become increasingly richer with deeper interaction, providing a more comprehensive memory base for new merchants, continuously alleviating cold start issues, and improving the accuracy of personalized services and user satisfaction.

[0088] The following section provides a detailed explanation of the process of "extracting tag information corresponding to accessible tags from the dialogue data to be processed based on accessible tags".

[0089] In an optional implementation, extracting tag information corresponding to the accessible tags from the dialogue data to be processed based on the accessible tags includes: performing feature extraction on the dialogue data to be processed based on the accessible tags to obtain a value vector, wherein the value vector is used to indicate whether the dialogue data to be processed contains information related to the accessible tags; and extracting tag information from the dialogue data to be processed based on a preset extraction rule corresponding to the accessible tags when the value vector indicates that the dialogue data to be processed contains information related to the accessible tags.

[0090] The value vector refers to the numerical judgment result output by the model. Each dimension of this vector corresponds to a binary classification probability score for different accessible labels, indicating whether the dialogue data to be processed contains valid information of a specific label category. For example, a score close to 1 in a certain dimension indicates that the dialogue is highly likely to contain the corresponding label information, while a score close to 0 indicates that it is unlikely to contain it.

[0091] Preset extraction rules refer to the extraction strategies configured for each accessible tag, usually in the form of prompt word templates. These rules explicitly tell the large language model how to identify, summarize, and format the target tag information from the dialogue, ensuring that the extraction results meet industry standards and structured requirements.

[0092] In an optional implementation, the platform deploys a finely tuned, small-sized text classification model. Taking the dialogue data to be processed as input and each accessible tag as the classification target, it outputs a binary value vector of 0 or 1. When the value vector indicates the presence of valid information, the platform generates an asynchronous retention message and delivers it to a message queue. The message queue asynchronously retrieves the task and calls the large language model to perform precise extraction based on preset extraction rules.

[0093] In an optional implementation, the small-size model can also output the confidence probability of each label dimension as a value vector, and set multiple thresholds on the platform to directly discard low-confidence dialogues, medium-confidence dialogues enter manual review or secondary judgment by the enhanced model, and high-confidence dialogues immediately trigger the large language model to extract and deliver asynchronous tasks.

[0094] Through one or more embodiments of this specification, a small-sized model is introduced for preliminary judgment. The platform can quickly identify and block worthless dialogues, and only trigger subsequent deep extraction of large language models for dialogue fragments with a high probability of containing valid information. While ensuring the quality of extraction, the frequency of calling high-cost models is significantly reduced, and the platform continuously accumulates user memory assets in a cost-effective manner.

[0095] As described in the optional implementation above, tags and tag information can be stored in a tag database. Tenants and their corresponding agents can determine accessible tags from the tag database. The tag database will be described below, with tags being the most fundamental data. Therefore, the addition and updating of tags in the tag database will be explained first. It should be noted that the platform, tenants (merchants), and third-party platforms (tag providers) can all add tags to the tag database, as detailed below: In an optional implementation, the platform operator, during the initial stage of system construction or iteration, independently defines and maintains a standardized tag set based on industry-wide needs and data governance experience. The platform's pre-set tags typically cover basic user attributes and cross-industry common dimensions, such as basic tags (city level), device tags (terminal type, operating system, network status), and behavioral characteristic tags (active time periods, login frequency, operational preferences), etc. The extraction rules for these tags are uniformly formulated by the platform, using standardized prompt word templates and normalized mapping tables to ensure consistency and comparability of results across different merchants.

[0096] In an optional implementation, the third-party platform can be an authoritative industry organization or data service provider. It joins the platform independently, opening its professional tag definitions and data capabilities to all or some merchants. These tags are characterized by high industry credibility and standardization. After joining, the third-party platform submits its industry-standard tags to the platform's tag library, such as the "academic level" and "professional category" tags provided by the Ministry of Education, and the "professional qualification level" and "skill certificate type" tags provided by the Ministry of Human Resources and Social Security.

[0097] The platform pre-sets tags to provide basic, general capabilities, while third-party platform tags adopt industry-standard specifications. This allows tenants (merchants) to directly subscribe to the tags they want to use from the tag database after joining the platform. Subscription is the process by which merchants select the necessary tags from the tag database based on their service needs after joining the platform. This mechanism enables merchants to quickly obtain standardized tag capabilities pre-set by the platform or provided by third parties without having to build a tag system from scratch.

[0098] In an optional implementation, merchants log in to the platform via a tenant client and access the tag database browsing interface. The tag database can be displayed categorized by source: platform-preset tags, merchant-defined tags, and third-party tags. Each tag displays metadata such as name, definition, data type, example value, update frequency, and subscription status, allowing merchants to assess its suitability. Merchants select the required tags based on their service type and service scenario. For example, a recruitment platform might select "career direction," "salary expectations," "job search location," and "start date." Merchants can select multiple tags simultaneously. Merchants submit subscription applications and rule configurations, which are then reviewed by the platform. The review includes: tag-service type matching, rule configuration completeness, data compliance, and whether there is excessive data collection. After approval, the subscribed tags are officially added to the merchant's accessible tag set, and the platform generates or updates the tag access code for the merchant's corresponding smart agent.

[0099] Optionally, merchants can adjust their subscribed tag sets at any time through the tenant client. Adding new tags requires resubmission for approval; deleting tags takes effect immediately, and previously extracted historical data is retained but not added again; modifying tag rules requires re-approval. The platform updates tag access codes in real time after changes to ensure permissions are synchronized with the subscription status. Tags subscribed by a merchant are effective by default for all intelligent agent applications under that merchant. For differentiated authorization, subsets can be further subdivided at the application level, forming a hierarchical control system of the merchant's full subscription set and application authorized subsets.

[0100] In addition, merchants can customize tags and corresponding preset extraction rules. In an optional implementation, before extracting tag information from the dialogue data to be processed based on the preset extraction rules corresponding to the accessible tags, the method further includes: upon receiving a tag addition request sent by a tenant client, determining the tag to be added carried in the tag addition request and the preset extraction rule corresponding to the tag to be added, wherein the tenant client is used to configure the first intelligent agent; and determining the tag to be added as an accessible tag; It should be noted that merchants (tenants) joining the platform can independently apply for and create tags based on the specific characteristics and expertise of their vertical service scenarios through the tenant client. These tags are an important supplement to the platform's standard tag system, enabling merchants to accurately characterize the segmented features of their target user groups and meet differentiated service needs.

[0101] As mentioned earlier, the tenant client can be the management software used by merchant operators to configure intelligent agent services, typically a web page or management backend. A tag addition request can be a message sent by the merchant through the tenant client to the platform server to add a new memory dimension. This request carries the definition information of the tag to be added and its corresponding preset extraction rules, serving as a trigger signal for the platform to expand its tag system and authorization scope. The tag to be added can be a new memory dimension that the merchant wishes to introduce into the platform's tag database and incorporate into its own accessible tag set. This tag can be a merchant-defined industry-specific tag or a refined variation of an existing tag, and it must be approved by the platform before it takes effect.

[0102] In an optional implementation, the tenant client can provide a visual tag-adding wizard to guide merchants through filling in basic information such as tag names, data types, and service descriptions. Pre-defined extraction rules can be configured using fill-in-the-blank templates in the rule editor. The platform can have a built-in rule validation engine to detect the completeness of prompts, the reasonableness of examples, and the compliance of output formats in real time. Once validation is passed, the rule is submitted for review.

[0103] In an optional implementation, tag information is extracted from the dialogue data to be processed based on preset extraction rules corresponding to the accessible tags, including: calling a large language model to extract tag information from the dialogue data to be processed based on preset extraction rules.

[0104] It should be noted that the preset extraction rules are extraction strategies configured by merchants or platforms for each tag, used to guide the large language model to output tag information in a structured manner from unstructured user dialogues. Among them, the prompt word template is the core carrier, which clearly informs the model of the extraction target, output format, example reference and boundary constraints, ensuring the standardization and consistency of the extraction results.

[0105] Optionally, the prompt template may include the following components: Role definition: Clearly define the role the model plays, enabling it to understand the dialogue from a specific perspective. For example: "You are a career planning consultant, skilled at identifying career-related information from user conversations." Extraction Target: Clearly describe the names of the tags to be extracted and their semantic connotations. For example: "Please extract the user's career direction information from the conversation, including the current job type, technology stack, industry field, etc." Output format: Specifies the structured format returned by the model to facilitate subsequent parsing and database entry. For example: "Please return in the following JSON format: {Label name: Career direction, Label value: Specific career name, Confidence level: Decimal number between 0 and 1}"; Example Reference: Provide positive and negative examples or boundary cases to help the model understand the extraction criteria. For example: "The user says I am a Java developer, so extract Java developer." Regarding the specific form of the prompt words for the preset extraction rules, different merchants (tenants) can set different prompt words for tags corresponding to different applications (intelligent agents), and are not limited to the above forms. For example, boundary constraints can be added to limit the extraction range and processing rules. For instance, a complete prompt word can be: Tag name: Personal hobbies; Prompt words: Role: You are a friendly personal assistant responsible for identifying, discovering, and summarizing users' personal interests from their conversations. Please summarize the user's interests into a single sentence and return it according to the specified format. Here are some examples: examples:[ AI: Hello, I am a sales assistant from XXX sports brand. How can I help you?

[0106] User: I want to buy a road racing bicycle, with a price range under 2000. summary: {userId: 2088XXXXX; nickName: Xiao Zhang; txt_info: User Xiao Zhang is interested in cycling; struc_info: {"userId": "2088XXXXX", "nickName": "Xiao Zhang", "hobby": ["bicycle"]}}] The platform runs a large language model, and through this preset extraction rule, it can extract the tag information corresponding to the personal hobby tag from the user's dialogue data.

[0107] In addition to adding tags and setting corresponding preset extraction rules via tag addition requests, merchants can also configure preset extraction rules for each subscribed or custom tag through the graphical interface or API of the tenant client. The platform provides a rule template library and a visual editor to lower the configuration threshold for merchants. Preset extraction rules submitted by merchants must be reviewed by the platform. The review may include rule completeness, example accuracy, output format compliance, and reasonableness of boundary constraints. Rules take effect after approval; otherwise, they are returned for modification.

[0108] Through one or more embodiments of this specification, and by employing a pre-configuration mechanism for tag addition requests and preset extraction rules, the platform achieves dynamic expansion of the tag system and standardized management of extraction logic. Merchants can independently define service tags in a low-code or even no-code manner, quickly responding to market changes and service iteration needs; the platform centrally reviews and controls data quality and compliance boundaries, avoiding tag redundancy and inconsistent extraction criteria; thus enabling the platform's memory service to possess scalability and industry adaptability.

[0109] The above section explained the tags in the tag database and the preset extraction rules for obtaining tag information. The following section provides a detailed explanation of the tag data in the tag database: In an optional implementation, storing the tag data in a tag database includes: identifying the tag data as short-term tag data and storing it in a short-term tag database, wherein the tag database includes a short-term tag database and a long-term tag database; deleting the short-term tag data if the storage time of the short-term tag data exceeds a preset time; and processing the short-term tag data in the short-term tag database into long-term tag data if the short-term tag data in the short-term tag database meets preset transfer conditions, and storing the long-term tag data in the long-term tag database, wherein the storage time of the long-term tag data is greater than the storage time of the short-term tag data.

[0110] It should be noted that the short-term tag database can be a storage area within the platform used to temporarily store short-term tag data. This database can be organized by user identifier, supports high-frequency writes and rapid expiration cleanup, and has low storage costs, but its data persistence is weaker than that of the long-term database. The long-term tag database can be a storage area within the platform used to persistently store processed and verified tag data. This database can also be organized by user identifier, and the data has high reliability and long-term reference value.

[0111] The preset time can be the maximum retention period set by the platform for short-term tag data, such as 7 days, 30 days, or 90 days. This period is dynamically adjusted based on service characteristics and data update frequency, and automatic cleanup is triggered after it is exceeded. The preset transfer conditions refer to the criteria that must be met for short-term tag data to be upgraded to long-term tag data, which may include occurrence frequency thresholds, confidence thresholds, and explicit user confirmation. These conditions are set by default by the platform or customized by the merchant through the tenant client.

[0112] In an optional implementation, the platform can physically or logically divide the tag database into short-term and long-term storage areas. Newly extracted tag data is first written to the short-term tag database as short-term tag data, recording the generation timestamp. The platform deploys scheduled tasks (e.g., hourly or daily) to scan the short-term tag database, performing two checks on each short-term tag data: first, checking if the storage time exceeds a preset time; if so, it is directly deleted or archived to cold storage; second, checking if preset transfer conditions are met, such as the tag appearing frequently in multiple user conversations reaching a threshold, or the confidence level of a single extraction exceeding a set standard, or the user explicitly requesting long-term storage via instruction. Short-term tag data that meets the transfer conditions enters the processing flow, generating long-term tag data, and is written to the long-term tag database.

[0113] Through one or more embodiments of this specification, the hierarchical design and management of short-term and long-term tag databases ensures that the rapid acceptance capability of the short-term database guarantees the timely capture and immediate availability of new information, while the strict access mechanism of the long-term database ensures the high reliability of shared memory.

[0114] The platform can pre-set the rules for determining whether to process short-term tag data, and the specific rules for the processing, which merchants (tenants) cannot configure. The processing and judgment processes are explained below.

[0115] In an optional implementation, processing short-term tag data into long-term tag data includes: obtaining standard tag definitions from a long-term tag database, wherein the standard tag definition includes at least one standard tag and its corresponding mapping rule; determining the target mapping rule and target tag corresponding to the short-term tag data; converting the tag information contained in the short-term tag data into target tag information according to the target mapping rule; and binding the target tag and target tag information into long-term tag data.

[0116] It should be noted that the standard label definition can be a predefined set of normalized labels and its associated processing rules in the long-term label database. Each standard label has a unique name, a clear data type, clear semantic boundaries, and mapping rules for mapping non-standard expressions to standard values. These mapping rules can be the processing logic that converts the original expressions in the short-term label data into the standard values ​​corresponding to the standard labels. These rules can be a thesaurus (e.g., "Java development" = "Java engineer" = "doing Java"), a regular expression pattern (e.g., matching various salary expression formats and unifying them to "yuan / month"), or a classification model (e.g., grouping multiple personality descriptions into "introverted / extroverted / neutral"). The target label refers to the standard label name to which the short-term label data should be assigned after mapping. This name is determined by the target mapping rule and is a normalized field identifier in the long-term label database.

[0117] The following examples illustrate mapping rules using two possible forms. Figure 4 A schematic diagram of a tag database for a tag data management method based on a multi-tenant environment, provided in one or more embodiments of this specification; as shown. Figure 4 As shown, the short-term tag database includes multiple short-term tag data (e.g. Figure 4 Data indicated by the circle in the middle, if it meets the preset transfer conditions, can be converted into long-term data tags in the long-term tag database (e.g., ...). Figure 4 The data indicated by the square in the middle), specifically: 1) Example of normalization rule: Tag name: Career direction; Short-term tag data: March 1st - Job posting A - "I'm a Java developer" - Java; March 15th - Training B - "Backend development, mainly using Java" - Backend development; April 2nd - Job opening A - "Java Engineer, 5 years experience" - Java Engineer; Mapping rules: Rule content: Unify the descriptions of Java, backend development, Java engineer, doing Java, doing Java, etc. into the standard value "Java development".

[0118] Long-term tag data: Career direction = Java development; Source records: [Java (Job posting A, 2026-03-01), Backend Development (Training B, 2026-03-15), Java Engineer (Job posting A, 2026-04-02)]; By unifying different expressions into a standard definition through normalization rules, the definition remains consistent when querying across merchants, thus avoiding service deviations caused by scattered values.

[0119] 2) Example of conflict resolution rules: Tag name: Job search location; Short-term tag data: February 1st - Recruitment A - City A; May 10 - Recruitment B - City B; Mapping rules: Rule content: When there is a conflict between the old and new values ​​for the same tag, the value with the latest timestamp will be used first; if the old value timestamp is within 30 days, the two values ​​will be retained for user confirmation; if the old value timestamp is more than 30 days old, the latest value will be directly overwritten.

[0120] Long-term tag data: Job search location = City B; Previous version: City A (2026-02-01, expired); Currently effective: City B (2026-05-10, Recruiting for B); By using a time threshold strategy to distinguish between user preferences that have changed and those that may be mentioned casually, a balance is struck between automated processing and user confirmation, ensuring the accuracy of long-term memory.

[0121] Through one or more embodiments of this specification, diverse user expressions are unified into standardized values, eliminating semantic ambiguity and misunderstanding when shared across merchants. High-quality standardized data in the long-term tag database provides a reliable profiling foundation for cold start scenarios. New merchants do not need to worry about inconsistent historical data and can directly reuse tag data uniformly managed by the platform. This improves the accuracy of user profiling, thereby improving the accuracy of the services provided to them.

[0122] In an optional implementation, if the short-term tag data in the short-term tag database meets the preset transfer conditions, the short-term tag data is processed into long-term tag data, including at least one of the following: if the number of times the short-term tag data is stored is greater than a preset number, the short-term tag data is processed into long-term tag data, wherein the preset number of positive short-term tag data is greater than the preset number of negative short-term tag data; if the confidence level of the short-term tag data is greater than a confidence level threshold, the short-term tag data is processed into long-term tag data, wherein the confidence level is used to indicate the confidence level of the tag information included in the short-term tag data during the extraction stage; if a long-term storage instruction is identified in the dialogue data to be processed, the short-term tag data is processed into long-term tag data.

[0123] Positive short-term label data can be labels describing users' positive preferences, affirmative attributes, or neutral facts. Examples include liking photography, being proficient in Python, or expecting a salary of 20k. This type of information has a positive effect on user profile construction, and the model's sensitivity to it is relatively low. Negative short-term label data, on the other hand, can be labels describing users' negative preferences, negative attributes, or sensitive avoidances. Examples include disliking overtime, rejecting sales positions, or not considering outsourcing. This type of information has a significant impact on user decisions, and the model needs to be more cautious in processing it to avoid misinterpretation or overreaction.

[0124] Confidence level specifically refers to the quantitative value of how confident a large language model is about the output results during the extraction stage. This value is usually presented in probability form, ranging from 0 to 1. The closer to 1, the more certain the model is about the extracted results; the closer to 0, the more likely the results are to be ambiguous or erroneous. The confidence threshold refers to the critical value for determining whether the extracted results are reliable.

[0125] Long-term storage instructions refer to explicit instructions expressed by the user in a conversation, requesting the system to remember specific information. Examples include "Please remember I am a Java developer" or "Please remember I don't want to go on a business trip." These instructions have a user-subjective confirmation attribute and have higher priority than automatic system judgment.

[0126] It's important to note that the short-term tag database functions like a draft area, widely accepting newly extracted information. However, the data quality varies greatly, and directly persisting all of it would lead to noise accumulation and distorted user profiles. By using a multi-dimensional combination of preset transfer conditions, the platform can filter out data truly worth retaining long-term from massive amounts of short-term data. Frequency thresholds filter out occasional, temporary information, confidence thresholds intercept low-quality results extracted by the model, and user commands assign the highest priority to explicit confirmations.

[0127] In an optional implementation, the platform maintains a frequency counter for each short-term tag data point. The counter increments each time a new extraction result for the same user and tag is added to the database. The platform can configure two sets of preset frequency thresholds: a higher threshold (e.g., ≥5 times) for positive tags such as career direction and skill certificates, and a lower threshold (e.g., ≥3 times) for negative tags such as sensitivity avoidance. A periodic scanning task traverses the short-term tag database, performing a frequency check on each data point. Positive tags that have reached a count of 5 trigger normalization processing and long-term writing; negative tags require accumulating to 3 times for the same processing. Tags that have not reached the threshold remain in the short-term database for further verification.

[0128] In an optional implementation, the platform requires the model to output a confidence score during the large language model extraction stage, and stores this score along with the tag information in the short-term tag database. During the configuration stage, a global confidence threshold (e.g., 0.85) and tag-level confidence thresholds are set (e.g., salary expectations are set to 0.9 due to sensitivity, and personal hobbies are set to 0.75 due to low sensitivity). During the transfer determination, if the confidence of short-term tag data exceeds the corresponding threshold, long-term storage is directly triggered without waiting for frequency accumulation, suitable for scenarios with high-quality model extraction and clear user expression. Simultaneously, the platform can monitor the dialogue data to be processed in real time. When it recognizes long-term storage instructions such as "Please remember," "Write this down for me," or "Don't ask me about this again," regardless of the current frequency or confidence level, it immediately marks the tag information as high priority, requiring secondary user confirmation or directly triggering long-term storage.

[0129] Through one or more embodiments of this specification, the frequency threshold filters out incidentally mentioned noise information, the confidence threshold intercepts uncertain results extracted by the model, and user instructions give explicit confirmation the highest priority. The three-layer mechanism works together to ensure high reliability and low false alarm rate of long-term data.

[0130] As mentioned earlier, the acquisition and transformation of data in the tag database have been explained. The platform's tag database may store tag data for multiple users. Each user can access the tag database through a user client running on their terminal device to view tag data related to themselves, as well as authorized merchants. Specifically: In an optional implementation, after storing the tag data in the tag database, the process includes: upon receiving a tag data viewing request sent by a user client, determining the user information to be verified carried in the tag data viewing request, wherein the user client is used to support dialogue between the target user and the first and second intelligent agents; retrieving the tag data to be viewed that matches the user information to be verified from the tag database, and returning the tag data to be viewed to the user client.

[0131] The user client is a software application that provides a dialogue and interaction portal for end users. It may be a mobile app, a webpage, or a mini-program. This client is distinct from the tenant client. It supports dialogue between target users and various intelligent agents, and also serves as a self-service portal for users to view and manage their own memory data.

[0132] It should be noted that a tag data viewing request refers to a data query request actively sent by a user through their client to the platform server. This request carries the user's identity credentials and requests the platform to return all or part of the currently stored tag data. It serves as the vehicle for the user to exercise their right to know and control their data. The user information to be verified refers to the user's identity identification information included in the tag data viewing request, such as user ID, session token, and biometric summary. The platform uses this information to verify whether the request initiator is the data subject, preventing unauthorized queries and information leakage. The tag data to be viewed refers to all tag records retrieved from the tag database that match the user information to be verified. This data includes positive and negative memory information accumulated by the user during interactions with different intelligent agents, as well as metadata such as the source, time, and confidence level of each tag.

[0133] In an optional implementation, the user client provides an entry point for "My Memory Data," which triggers a request to view tag data upon user access. After verifying the user's identity, the platform retrieves all tag records for that user from the tag database, categorizing and aggregating them by dimensions such as source agent, tag type, and generation time, and returning them to the user client in the form of visual cards or a timeline. Each tag data entry can display complete metadata such as tag name, tag value, source merchant, first extraction time, last update time, and frequency of occurrence. Users can expand to view details or collapse to browse an overview. For sensitive tags such as salary expectations and health status, the platform can highlight or issue warning icons to alert users and provide a one-click authorization revocation option.

[0134] In an optional implementation, the user client embeds a shortcut to view stored information within the chat interface. For example, when a user inputs a natural language command such as "View my profile" or "What tags do I have?", the client automatically parses the intent and sends a tag data viewing request. The platform returns a simplified version of the tag data to be viewed, containing only a summary of tags relevant to the current conversation, avoiding information overload. Users can ask follow-up questions about specific tags, such as "Who saved my salary information?" or "How was my career path determined?" The platform immediately returns the complete metadata for that tag and the extracted source conversation snippet.

[0135] Figure 5 A schematic diagram of a user client for a tag data management method based on a multi-tenant environment provided in one or more embodiments of this specification; as shown. Figure 5As shown in (a), the user client can display multiple interactive controls (such as My Memory Data Entry, Switch Account), user information (such as Username, User Avatar), etc. through the terminal. After the user interacts with the "My Memory Data Entry" control, the user client can display... Figure 5 The interface shown in (b) displays the user's corresponding tag data (career direction = Java development, switch to any direction = AI, salary expectation = 25k, job search location = city A).

[0136] The above are optional implementation methods for users to view data through a user client. Below are optional implementation methods for deleting and updating tag data after viewing: Optionally, a user browses the tag data to be viewed through their user client and finds a tag they no longer wish for a merchant to use. The user selects the tag and clicks the "Revoke Authorization" button. The user client sends an authorization revocation request to the platform, carrying the user information to be verified, the target tag name, and the authorization scope (global revocation or specific merchant revocation). After verifying the user's identity, the platform removes the user's authorization record for the target tag from the permission mapping table or marks it as revoked. Afterward, when any agent queries this user, the platform filters out revoked tags and does not return them. Historical data already written to the long-term tag database can be retained but marked as invalid, or physically deleted completely according to the user's choice.

[0137] Optionally, if a user discovers that a merchant's stored tag data is biased or excessively collected, they can use the "Delete by Source" function on their client to specify the target merchant or agent identifier. After platform verification, the platform retrieves all tag records from the specified agent in the tag database and returns them to the user in a list for confirmation. The user selects the specific items to be deleted or selects all and submits a deletion request. The platform performs logical or physical deletion, simultaneously clears the cache layer and index associations, and notifies the merchant that their accessible tag set has changed to prevent subsequent query anomalies.

[0138] Optionally, if a user finds an inaccurate tag value while viewing the tag data (e.g., "Career Direction" = Java Developer, but actually "Product Manager"), the user can click on the tag to enter edit mode, manually enter the new value "Product Manager," and submit an update request. After verifying the user's identity and editing permissions, the platform writes the new value to the long-term tag database, overwriting the old value or generating a new version record. The update time is the current timestamp, and the source is marked as the user's manual correction. This update takes effect immediately, and all subsequent agent queries will return the latest value, ensuring the accuracy of the profile.

[0139] Through one or more embodiments of this specification, and via the tag data viewing mechanism on the user client, the platform achieves closed-loop governance of the entire memory service process—supporting not only merchant-side query and consumption but also user-side review and control. User control is effectively implemented, enabling them to proactively adjust the scope of authorization or correct erroneous information based on the viewing results.

[0140] The above embodiments of this specification can be regarded as four main parts: tag processing, tag assets, memory services, and intelligent agent applications. The tag processing part mainly includes tag definition, merchant subscription, and data access; the tag asset part mainly includes tag storage, updating, and management; the memory service part mainly includes querying, sorting, fusion, and retention; and the intelligent agent application part mainly includes services for actual use of memory. Figure 6 A schematic diagram illustrating a tag data management method based on a multi-tenant environment, provided for one or more embodiments of this specification; as shown. Figure 6 As shown, the four main execution parts are clearly divided by dashed lines. Specifically: S602, Tag Database Construction; The platform builds a tag database based on external data and defines standardized memory dimensions. See the platform's pre-defined tagging process above for details.

[0141] S604, accepts customer subscriptions; Receive configuration information or tag addition requests sent by merchants through the tenant client, subscribe to the required tags, and configure preset extraction rules.

[0142] S606, Generate tag access code; The platform generates tag access codes based on tenant identifiers, agent identifiers, and accessible tags. Access codes can be generated using methods such as concatenation, compression, or encryption.

[0143] S608, query the tag database; The platform receives an information query request from the first intelligent agent, parses the tag access code to determine accessible tags, and retrieves the corresponding tag information from the tag database based on the user information. It then determines the accessible tags, retrieves the tag information, and returns the result to the first intelligent agent.

[0144] S610, Generate dialogue content; The first intelligent agent generates personalized dialogue content with the target user based on the accessible tags and tag information returned by the platform. Specifically, accessible tags and tag information are sent to the first intelligent agent so that it can generate dialogue content with the target user.

[0145] S612, Generate dialogue data to be processed; During the interaction between the first intelligent agent and the target user, unprocessed dialogue data is generated and asynchronously reported to the platform. This means obtaining the unprocessed dialogue data sent by the first intelligent agent.

[0146] S614, retain pending dialogue data; The platform obtains the dialogue data to be processed sent by the first intelligent agent, extracts the tag information based on the accessible tags, binds it as tag data and stores it in the tag database.

[0147] S616, Extract short-term tag data; The platform extracts tag information from the dialogue data, forming short-term tag data which is then stored in the short-term tag database. In other words, the tag data is identified as short-term tag data and stored in the short-term tag database.

[0148] S618, converted to long-term tag data; The platform periodically scans the short-term tag database, performs normalization processing on short-term tag data that meets the preset transfer conditions, and converts it into long-term tag data to be stored in the long-term tag database.

[0149] Figure 6 For detailed procedures of each step, please refer to one or more embodiments in the above specification, which will not be repeated here.

[0150] It is understood that the above embodiments are merely examples, and modifications can be made to the above embodiments in actual implementation. Those skilled in the art will understand that any modifications to the above embodiments that do not require creative effort fall within the protection scope of one or more embodiments of this specification, and will not be described again in the embodiments.

[0151] Based on the same inventive concept, one or more embodiments of this specification also provide a tag data management device based on a multi-tenant environment. Figure 7 This is a structural block diagram of the tag data management device based on a multi-tenant environment. (Example:) Figure 7 As shown, the tag data management device 700 based on a multi-tenant environment may include: The tag determination module 702 is used to determine the accessible tag corresponding to the first intelligent agent upon receiving an information query request sent by the first intelligent agent, wherein the information query request includes user information of the target user; the information acquisition module 704 is used to obtain the tag information corresponding to the accessible tag from the tag database based on the user information, wherein the tag information is generated based on the dialogue data between the second intelligent agent and the target user; the sending module 706 is used to send the accessible tag and tag information to the first intelligent agent so that the first intelligent agent can generate dialogue content with the target user based on the accessible tag and tag information.

[0152] In one possible implementation, the apparatus further includes: an information extraction module, configured to acquire the dialogue data to be processed sent by the first intelligent agent and determine the accessible tag corresponding to the first intelligent agent; extract tag information corresponding to the accessible tag from the dialogue data to be processed based on the accessible tag; bind the accessible tag and the tag information into tag data, and store the tag data in a tag database.

[0153] In one possible implementation, the information extraction module is further configured to: extract features from the dialogue data to be processed based on the accessible tags to obtain a value vector, wherein the value vector is used to indicate whether the dialogue data to be processed contains information related to the accessible tags; and extract tag information from the dialogue data to be processed based on the preset extraction rules corresponding to the accessible tags when the value vector indicates that the dialogue data to be processed contains information related to the accessible tags.

[0154] In one possible implementation, the information extraction module is further configured to: upon receiving a tag addition request sent by a tenant client, determine the tag to be added carried in the tag addition request and the preset extraction rule corresponding to the tag to be added, wherein the tenant client is used to configure the first intelligent agent; determine the tag to be added as an accessible tag; and call the large language model to extract tag information from the dialogue data to be processed based on the preset extraction rule.

[0155] In one possible implementation, the information extraction module is further configured to: identify the tag data as short-term tag data and store it in a short-term tag database, wherein the tag database includes a short-term tag database and a long-term tag database; if the storage time of the short-term tag data exceeds a preset time, delete the short-term tag data; if the short-term tag data in the short-term tag database meets preset transfer conditions, process the short-term tag data into long-term tag data and store the long-term tag data in the long-term tag database, wherein the storage time of the long-term tag data is greater than the storage time of the short-term tag data.

[0156] In one possible implementation, the information extraction module is further configured to: obtain standard tag definitions from the long-term tag database, wherein the standard tag definitions include at least one standard tag and its corresponding mapping rule; determine the target mapping rule and target tag corresponding to the short-term tag data; convert the tag information contained in the short-term tag data into target tag information according to the target mapping rule; and bind the target tag and target tag information into long-term tag data.

[0157] In one possible implementation, the information extraction module is further configured to: process short-term tag data into long-term tag data when the number of times short-term tag data is stored is greater than a preset number, wherein the preset number of times positive short-term tag data corresponds to is greater than the preset number of times negative short-term tag data corresponds to; process short-term tag data into long-term tag data when the confidence level of short-term tag data is greater than a confidence level threshold, wherein the confidence level is used to indicate the confidence level of the tag information included in the short-term tag data during the extraction stage; and process short-term tag data into long-term tag data when a long-term storage instruction is identified in the dialogue data to be processed.

[0158] In one possible implementation, the information extraction module is further configured to: upon receiving a tag data viewing request sent by a user client, determine the user information to be verified carried in the tag data viewing request, wherein the user client is used to support dialogue between the target user and the first and second intelligent agents; retrieve the tag data to be viewed that matches the user information to be verified from the tag database, and return the tag data to be viewed to the user client.

[0159] In one possible implementation, the tag determination module 702 is further configured to: upon receiving configuration information sent by the tenant client, determine at least one request authorization tag carried in the configuration information as an accessible tag based on the service type of the first intelligent agent, wherein the tenant client is used to configure the first intelligent agent; generate a tag access code based on the tenant identifier of the tenant client, the intelligent agent identifier of the first intelligent agent, and the accessible tag; and determine the accessible tag corresponding to the first intelligent agent according to the tag access code.

[0160] In one possible implementation, the tag determination module 702 is further configured to: concatenate the tenant identifier, the agent identifier, and the accessible tag to obtain a tag access code; concatenate the tenant identifier, the agent identifier, and the accessible tag, and obtain a tag access code according to a preset compression method, wherein the number of bits in the tag access code is fixed; concatenate the tenant identifier, the agent identifier, and the accessible tag, and obtain encrypted information according to a preset encryption method; and compose a tag access code based on the encrypted information, the tenant identifier, the agent identifier, and the accessible tag.

[0161] See Figure 8 , Figure 8 This is a structural block diagram of an electronic device provided for one or more embodiments of this specification. Figure 8 As shown, the electronic device 800 may include a processor 802 and a memory 804; the memory 804 may be coupled to the processor 802. It is worth noting that... Figure 8This is an example; other types of structures can also be used to supplement or replace this structure to achieve telecommunications functions or other functions. The electronic device can be a server, client, or other intermediate device in a software development system.

[0162] In one possible implementation, the functionality of the tag data management device 700 based on a multi-tenant environment can be integrated into the processor 802. The processor 802 can be configured to perform some or all of the steps described in any of the preceding method embodiments.

[0163] In another possible implementation, the tag data management device 700 based on the multi-tenant environment can be configured separately from the processor 802. For example, the tag data management device 700 based on the multi-tenant environment can be configured as a chip connected to the processor 802, and the tag data can be queried through the control of the processor 802.

[0164] Furthermore, in some alternative embodiments, the electronic device 800 may also include: a communication module, an input unit, an audio processor, a display, a power supply, etc. It is worth noting that the electronic device 800 is not necessarily required to include these components. Figure 8 All components shown; in addition, the electronic device 800 may also include Figure 8 For components not shown, please refer to existing technologies.

[0165] This specification provides one or more embodiments of a computer-readable storage medium capable of implementing all steps of the tag data management method based on a multi-tenant environment described in the above embodiments. The computer-readable storage medium stores a computer program that, when executed by a processor, implements all steps of the tag data management method based on a multi-tenant environment described in the above embodiments. Specific steps are described in the preceding embodiments and will not be repeated here.

[0166] In addition, one or more embodiments of this specification also provide a computer program product capable of implementing all the steps in the above embodiments of the tag data management method based on a multi-tenant environment; the computer program product includes: a computer program or instructions, which, when executed on a computer, cause the computer to implement all the steps of the tag data management method based on a multi-tenant environment in the above embodiments. Specific steps can be found in the foregoing embodiments and will not be repeated here.

[0167] The foregoing has described specific embodiments of this specification. In other possible implementations, some or all of the actions or steps described in the above embodiments may be performed in a different order than that shown in the above embodiments, and the desired result may still be achieved. Furthermore, the processes depicted in the accompanying drawings do not necessarily require a specific or sequential order to achieve the desired result. In some implementations, multitasking and parallel processing are possible or may be advantageous.

[0168] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the device and system embodiments are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0169] It should be noted that, unless otherwise specified, one or more embodiments of this specification and the features thereof can be combined with each other. This specification is not limited to any single aspect, nor to any single embodiment, nor to any combination and / or substitution of such aspects and / or embodiments. Furthermore, each aspect and / or embodiment of one or more embodiments of this specification can be used alone, or in combination with one or more other aspects and / or embodiments thereof.

[0170] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of one or more embodiments of this specification, and are not intended to limit them. Although one or more embodiments of this specification have been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of one or more embodiments of this specification, and they should all be covered within the scope of the claims and the specification of one or more embodiments of this specification.

[0171] The foregoing description of one or more embodiments of this specification has been provided in conjunction with optional implementation methods. However, these embodiments are merely exemplary and serve only an illustrative purpose. Based on this, various substitutions and modifications can be made to one or more embodiments of this specification, all of which fall within the protection scope of one or more embodiments of this specification.

Claims

1. A tag data management method based on a multi-tenant environment, characterized in that, include: Upon receiving an information query request sent by a first intelligent agent, determine the accessible tag corresponding to the first intelligent agent, wherein the information query request includes user information of the target user; Based on the user information, the tag information corresponding to the accessible tag is obtained from the tag database, wherein the tag information is generated based on the dialogue data between the second agent and the target user; The accessible tag and the tag information are sent to the first intelligent agent so that the first intelligent agent can generate dialogue content with the target user based on the accessible tag and the tag information.

2. The method according to claim 1, characterized in that, After sending the accessible tag and the tag information to the first agent, the method further includes: Obtain the dialogue data to be processed sent by the first intelligent agent, and determine the accessible tag corresponding to the first intelligent agent; Based on the accessible tags, extract tag information corresponding to the accessible tags from the dialogue data to be processed; The accessible tags and the tag information are bound together as tag data, and the tag data is stored in the tag database.

3. The method according to claim 2, characterized in that, The step of extracting tag information corresponding to the accessible tags from the dialogue data to be processed based on the accessible tags includes: Based on the accessible tags, feature extraction is performed on the dialogue data to be processed to obtain a value vector, wherein the value vector is used to indicate whether the dialogue data to be processed contains relevant information of the accessible tags; When the value vector indicates that the dialogue data to be processed contains information related to the accessible tags, the tag information is extracted from the dialogue data to be processed based on the preset extraction rules corresponding to the accessible tags.

4. The method according to claim 3, characterized in that, Before extracting the tag information from the dialogue data to be processed based on the preset extraction rules corresponding to the accessible tags, the method further includes: Upon receiving a tag addition request sent by a tenant client, the system determines the tag to be added carried in the tag addition request and the preset extraction rule corresponding to the tag to be added, wherein the tenant client is used for tenant configuration of the first intelligent agent; The tag to be added is identified as the accessible tag; The step of extracting the tag information from the dialogue data to be processed based on the preset extraction rules corresponding to the accessible tags includes: The large language model is invoked to extract the tag information from the dialogue data to be processed based on the preset extraction rules.

5. The method according to claim 2, characterized in that, The step of storing the tag data in the tag database includes: The tag data is identified as short-term tag data and stored in a short-term tag database, wherein the tag database includes the short-term tag database and the long-term tag database; If the storage time of the short-term tag data exceeds a preset time, the short-term tag data will be cleared; If the short-term tag data in the short-term tag database meets the preset transfer conditions, the short-term tag data is processed into long-term tag data and stored in the long-term tag database, wherein the storage time of the long-term tag data is longer than the storage time of the short-term tag data.

6. The method according to claim 5, characterized in that, The process of converting the short-term tag data into long-term tag data includes: Obtain the standard tag definitions from the long-term tag database, wherein the standard tag definitions include at least one standard tag and its corresponding mapping rules; Determine the target mapping rules and target tags corresponding to the short-term tag data; The tag information contained in the short-term tag data is converted into target tag information according to the target mapping rule; The target tag and the target tag information are bound to the long-term tag data.

7. The method according to claim 5, characterized in that, When the short-term tag data in the short-term tag database meets the preset transfer conditions, the short-term tag data is processed into long-term tag data, including at least one of the following: If the number of times the short-term tag data is stored is greater than a preset number, the short-term tag data is processed into long-term tag data, wherein the preset number of times the short-term tag data is positive is greater than the preset number of times the short-term tag data is negative. If the confidence level of the short-term label data is greater than the confidence level threshold, the short-term label data is processed into long-term label data, wherein the confidence level is used to indicate the confidence level of the label information included in the short-term label data during the extraction stage; If a long-term storage instruction is identified in the dialogue data to be processed, the short-term tag data is processed into long-term tag data.

8. The method according to any one of claims 5 to 7, characterized in that, After storing the tag data in the tag database, the process includes: Upon receiving a tag data viewing request sent by a user client, the user client determines the user information to be verified carried in the tag data viewing request, wherein the user client is used to support the target user to have a dialogue with the first intelligent agent and the second intelligent agent. The system retrieves the tag data that matches the user information to be verified from the tag database and returns the tag data to the user client.

9. The method according to claim 1, characterized in that, Before determining the accessible tag corresponding to the first intelligent agent, the process includes: Upon receiving configuration information sent by the tenant client, at least one request authorization tag carried in the configuration information is determined as an accessible tag based on the service type of the first agent, wherein the tenant client is used by the tenant to configure the first agent; A tag access code is generated based on the tenant identifier of the tenant client, the agent identifier of the first agent, and the accessible tag; The determination of the accessible tag corresponding to the first intelligent agent includes: The accessible tag corresponding to the first intelligent agent is determined based on the tag access code.

10. The method according to claim 9, characterized in that, The generation of a tag access code based on the tenant identifier of the tenant client, the agent identifier of the first agent, and the accessible tag includes at least one of the following: The tenant identifier, the agent identifier, and the accessible tag are concatenated to obtain the tag access code; The tenant identifier, the agent identifier, and the accessible tag are concatenated and then compressed according to a preset method to obtain the tag access code, wherein the number of bits in the tag access code is fixed. The tenant identifier, the agent identifier, and the accessible tag are combined to obtain encrypted information using a preset encryption method; the encrypted information, the tenant identifier, the agent identifier, and the accessible tag are then used to form the tag access code.

11. A tag data management device based on a multi-tenant environment, characterized in that, include: The tag determination module is used to determine the accessible tag corresponding to the first intelligent agent when receiving an information query request sent by the first intelligent agent, wherein the information query request includes user information of the target user; The information acquisition module is used to acquire tag information corresponding to the accessible tag from the tag database based on the user information, wherein the tag information is generated based on the dialogue data between the second intelligent agent and the target user; The sending module is used to send the accessible tag and the tag information to the first intelligent agent, so that the first intelligent agent can generate dialogue content with the target user based on the accessible tag and the tag information.

12. An electronic device, characterized in that, The electronic device includes: Memory, used to store computer program products; A processor is configured to execute a computer program product stored in the memory, wherein, when the computer program product is executed, it implements the method described in any one of claims 1-10.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions, which, when executed, implement the method described in any one of claims 1-10.

Images