Methods for constructing a character background knowledge base and training a dialogue model

Abstract

This specification provides a method for constructing a character background knowledge base and a method for training a dialogue model. The method for constructing the character background knowledge base includes: acquiring character background data of a virtual character; extracting entities and relationships between entities from the character background data; constructing a background knowledge graph of the virtual character using entities as nodes and relationships as edges; assigning corresponding weight information to each layer of the knowledge graph to obtain a background knowledge graph containing weight information; and constructing a background knowledge base of the virtual character based on the background knowledge graph containing weight information. The background knowledge base is used as the context for retrieval enhancement generation of the dialogue model for training the virtual character. This can solve the problems of the virtual character generating dialogue content that is inconsistent with its role positioning, logically contradictory, and outputting responses that deviate from the user's expression focus due to a lack of background knowledge support, thereby improving the immersion of the user in the dialogue process with the virtual character.

Description

Technical Field

[0001] The embodiments in this specification relate to the field of digital cultural product technology, and in particular to the construction method of the character background knowledge base and the training method of the dialogue model. Background Technology

[0002] With the continuous development of digital cultural products, users' demand for dialogue and interaction between themselves and virtual characters is constantly increasing, in order to enhance users' sense of immersion in virtual scenarios.

[0003] Existing methods for enabling virtual characters to converse with users can be mainly categorized as follows: Rule-based and script-based dialogue systems: Developers pre-write numerous dialogue branches, keyword trigger rules, and fixed response scripts. The system matches and returns preset responses from a script library based on user-input keywords or dialogue state. While this method offers strong controllability, the dialogue is rigid, lacks flexibility, and cannot respond outside of preset rules. Retrieval-based dialogue models: This method relies on a large dialogue corpus. When a user inputs a sentence, the system calculates similarity and retrieves the most matching context and corresponding response from the corpus as output. Compared to pure rule-based systems, it can provide more diverse responses, but its response quality depends entirely on the size and quality of the corpus. It cannot perform semantic understanding and contextual logic generation, easily resulting in irrelevant or outdated answers. Models based on traditional machine learning and early natural language generation: These models utilize statistical machine learning methods to generate responses. While this method can generate non-preset text, it easily produces generic, vague, or meaningless responses and has significant shortcomings in long-term dialogue consistency, character personality maintenance, common-sense reasoning, and emotional expression.

[0004] In conclusion, existing technologies cannot simulate real dialogue with virtual characters, and the output dialogue is difficult to accurately respond to the focus of the user's expression, resulting in a low level of user immersion. Summary of the Invention

[0005] In view of this, embodiments of this specification provide a method for constructing a role background knowledge base. One or more embodiments of this specification also relate to a dialogue model training method, a role control method, a program update method, a program product, a computing device, and a computer-readable storage medium, to address the technical deficiencies existing in the prior art.

[0006] According to a first aspect of the embodiments of this specification, a method for constructing a character background knowledge base is provided, comprising: Obtain the character background data of the virtual character; Extract the relationships between entities from the character background data; Using entities as nodes and relationships as edges, a background knowledge graph for virtual characters is constructed. The background knowledge graph includes at least one layer of knowledge graph, and the entity types of entities in each layer of knowledge graph are different. By assigning corresponding weight information to each layer of the knowledge graph, a background knowledge graph containing the weight information is obtained. Based on a background knowledge graph containing weighted information, a background knowledge base for virtual characters is constructed. This background knowledge base provides relevant background knowledge as context for retrieval enhancement generation in training the dialogue model of the virtual characters.

[0007] According to a second aspect of the embodiments of this specification, a dialogue model training method is provided, comprising: Obtain a sample dataset, which includes sample questions and labeled responses. The sample questions contain at least one type of entity and its corresponding weight information. The sample question is input into the dialogue model of the virtual character. Based on at least one type of entity and its corresponding weight information, the relevant background knowledge of the virtual character is retrieved from the background knowledge base. The background knowledge base is constructed according to the above-mentioned method for constructing the character background knowledge base. Using relevant background knowledge as context, generate predicted responses to sample questions; Calculate the loss value based on the predicted response and the labeled response; The model parameters of the dialogue model are adjusted based on the loss value to obtain the trained target dialogue model of the virtual character.

[0008] According to a third aspect of the embodiments of this specification, a role control method is provided, comprising: The target problem received from the front end; The target problem is analyzed to obtain the entity types of entities in the target problem and their corresponding weight information; The target question, the entity types of the entities in the target question, and their corresponding weight information are input into the target dialogue model of the virtual character, so that the target dialogue model of the virtual character can reason about the target question based on the entity types of the entities and their corresponding weight information and generate the target answer. The target dialogue model of the virtual character is trained by the dialogue model training method described above. Output the target response to the front end.

[0009] According to a fourth aspect of the embodiments of this specification, a program update method is provided, comprising: The dialogue model of the virtual character and the target dialogue model are obtained, and the target dialogue model is deployed to the first server. The target dialogue model is trained using the dialogue model training method described above. Obtain the first running data of the target dialogue model on the first server, and obtain the second running data of the dialogue model on the second server; The first and second running data are compared, and the result of the comparison is used to determine whether to deploy the target dialogue model to the second server.

[0010] According to a fifth aspect of the embodiments of this specification, a program product is provided, including a dialogue module, an item generation module, and a numerical balance module. The dialogue module is configured to receive the target question sent by the front end, use the target dialogue model of the virtual character to reason about the target question, and generate the target answer. The target dialogue model of the virtual character is trained by the dialogue model training method described above. The item generation module is configured to generate target items for the user to use based on the user's input instructions; The numerical balancing module is configured to acquire user operation data in the target program and adjust the items generated by the item generation module based on the operation data.

[0011] According to a sixth aspect of the embodiments of this specification, a computing device is provided, comprising: Memory and processor; The memory is used to store computer programs / instructions, and the processor is used to execute the computer programs / instructions, which implement the steps of the above method when executed by the processor.

[0012] According to a seventh aspect of the embodiments of this specification, a computer-readable storage medium is provided that stores a computer program / instructions that, when executed by a processor, implement the steps of the above-described method.

[0013] This specification provides an embodiment of a method for constructing a role background knowledge base, comprising: Obtain the background data of the virtual character; extract the entities and the relationships between them from the background data; Using entities as nodes and relationships as edges, a background knowledge graph for virtual characters is constructed. The background knowledge graph includes at least one layer of knowledge graph, with different entity types in each layer. Corresponding weight information is assigned to each layer of knowledge graph to obtain a background knowledge graph containing weight information. Based on the background knowledge graph containing weight information, a background knowledge base for virtual characters is constructed. The background knowledge base is used to provide relevant background knowledge as the context for retrieval enhancement generation when training the dialogue model of virtual characters. It can transform the background knowledge of a character into a structured knowledge system rich in semantic logic and hierarchical entity weight information. As a reliable knowledge source in the retrieval enhancement generation process, it enables the dialogue model to selectively retrieve and learn the character background knowledge most relevant to the current context from different types of entities based on the weight information of each knowledge layer during the training phase. This avoids logical confusion or information overload caused by the mixing of knowledge dimensions. It also enables virtual characters to generate logically consistent, stylistically consistent dialogue content that matches the user's focus based on their own role positioning and the implicit emphasis in the user's expression. This solves the problems of virtual characters generating dialogue content that does not match their role positioning, has logical contradictions, and outputs responses that deviate from the user's expression focus due to the lack of background knowledge support, thus improving the immersion of users in the dialogue process with virtual characters. Attached Figure Description

[0014] Figure 1 This is a flowchart illustrating a method for constructing a role background knowledge base according to one embodiment of this specification; Figure 2 This is a schematic diagram of the structure of a multi-layer knowledge graph provided in one embodiment of this specification; Figure 3 This is a schematic diagram of another multi-layer knowledge graph structure provided in one embodiment of this specification; Figure 4 This is a flowchart illustrating a dialogue model training method provided in one embodiment of this specification; Figure 5 This is a flowchart illustrating a role control method provided in one embodiment of this specification; Figure 6 This is a flowchart illustrating a program update method provided in one embodiment of this specification; Figure 7 This is a schematic diagram of the structure of a program product provided in one embodiment of this specification; Figure 8 This is a structural block diagram of a computing device provided in one embodiment of this specification. Detailed Implementation

[0015] Many specific details are set forth in the following description to provide a full understanding of this specification. However, this specification can be implemented in many other ways than those described herein, and those skilled in the art can make similar extensions without departing from the spirit of this specification. Therefore, this specification is not limited to the specific implementations disclosed below.

[0016] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of this specification. The singular forms “a,” “described,” and “the” as used in one or more embodiments of this specification and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in one or more embodiments of this specification refers to and includes any or all possible combinations of one or more associated listed items.

[0017] It should be understood that although the terms first, second, etc., may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first may also be referred to as second without departing from the scope of one or more embodiments of this specification, and similarly, second may also be referred to as first. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to a determination."

[0018] Furthermore, it should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in one or more embodiments of this specification are all information and data authorized by the user or fully authorized by all parties. Moreover, the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0019] First, the terms and concepts used in one or more embodiments of this specification will be explained.

[0020] Virtual characters: Virtual characters are digital images that exist in a digital environment and have specific settings and interactive capabilities. Examples include virtual customer service representatives in enterprise service scenarios, virtual tutors in online education, virtual idols or virtual anchors in digital entertainment, and virtual avatars of users in the metaverse.

[0021] Character background data: Character background data consists of text, images, or structured data used to describe a virtual character's identity, experiences, personality, social relationships, and worldview. Examples include an official character profile, historical interaction records, professional knowledge base documents, and background stories posted on social media for a brand's virtual spokesperson.

[0022] Entities: An entity is an objective thing or abstract concept with independent meaning identified from the character's background data. For example, an entity can be the virtual character itself, its affiliated organization, related products, key service events, and personality traits.

[0023] Knowledge graph: A knowledge graph is a technique that uses a graph structure to model knowledge and data, where nodes represent entities and edges represent semantic relationships between entities. For example, a knowledge graph can represent knowledge such as "Virtual customer service A (node) is proficient in (edge) business B (node)".

[0024] LoRA: Low-Rank Adaptation (LoRA) is a parameter-efficient fine-tuning technique that injects trainable low-rank decomposition matrices into the linear layers of a pre-trained model and freezes the original model weights to efficiently adapt to new tasks with a small number of parameters. For example, when training a dialogue model, only a small number of newly added adapter parameters need to be trained and stored to enable the model to learn the domain knowledge, service scripts, and communication styles of a specific virtual character.

[0025] Computing devices: Computing devices are computer systems designed to perform one or more specific tasks. Compared to personal mainframes, they are weaker in performance but have significant advantages in terms of size and power consumption. They are commonly used in various electronic and mechanical control systems.

[0026] This specification provides a method for constructing a character background knowledge base. This specification also relates to a dialogue model training method, a character control method, a program update method, a program product, a computing device, and a computer-readable storage medium, which are described in detail in the following embodiments.

[0027] See Figure 1 , Figure 1 The flowchart illustrates a method for constructing a role background knowledge base according to an embodiment of this specification, applied to the backend of a program development system, and includes the following specific steps: Step 102: Obtain the character background data of the virtual character.

[0028] The embodiments in this specification are applied to scenarios where dialogue models need to be optimized. For example, when developing a digital cultural product, it is necessary to build dialogue capabilities with profound cultural connotations, unique divine attributes, and epic memories for the numerous virtual characters (such as gods, heroes, and elves) that originate from the mythological system, in order to create an interactive experience with a high degree of immersion and cultural tension.

[0029] A virtual character is a digital image that exists in a digital environment and has specific settings and interactive capabilities. For example, in a certain digital cultural product, there is a "virtual character A" who is the goddess of wisdom and war from a certain mythology.

[0030] Character background data consists of text, images, or structured data used to describe a virtual character's identity, experiences, personality, social relationships, and worldview. For example, the character profile of "Virtual Character A" includes her divine position as "one of the twelve Olympian gods, goddess of wisdom, war, art, and crafts," her origin as "born from the head of Virtual Character B, fully armed," her landmark event as "competing with Virtual Character D for the protection of city-state A and winning, gifting humanity an olive tree," her personality traits as "wise, just, brave, and a protector of city-states and heroes," her important connections as "Virtual Character B (father), Virtual Character E (who co-created humanity), Virtual Character C (close friend / accidental killer)," and detailed descriptions of her sacred objects such as "a divine shield, a spear, and an owl."

[0031] Optionally, one way to obtain the background data of a virtual character is to read it from the structured character database of the product content management system. Another way to obtain the background data of a virtual character is to use natural language processing technology to automatically extract descriptive fragments related to the character from unstructured texts such as relevant mythological epics, product plot scripts, and character biographies. This specification does not limit this approach.

[0032] For example, for the character "virtual character A", the complete character setting file in Extensible Markup Language (XML) format is obtained from the "Mythological Character Library" in the product backend, as well as the digital text summary of the relevant chapter in a linked novel.

[0033] Step 102 obtains the background data of the virtual character, providing a detailed and multi-dimensional data foundation for extracting entities and relationships between entities from the background data.

[0034] Step 104: Extract the entities and their relationships from the character background data.

[0035] An entity is an objective thing or abstract concept with independent meaning that is identified from the background data of a character. For example, entities can be extracted from the background data of "virtual character A": "virtual character A", "virtual character B", "virtual character D", "virtual character E", "virtual character C", "city-state A", "Aegis", "olive tree", "wisdom godhood", "the grief of virtual character A (the incident of accidentally killing virtual character C)", etc.

[0036] Associations are data representations that express the semantic connections between two entities, identified from role background data. They are used to formally define interactions, attribute affiliations, event associations, or logical dependencies between entities. For example, the types of associations between the aforementioned entities may include, but are not limited to: kinship (e.g., "father"), competition / antagonism (e.g., "competitor"), cooperation (e.g., "collaborator"), ownership (e.g., "own", "protect"), event participation (e.g., "participate", "cause"), attribute / trait relationships (e.g., "possess divinity", "symbol"), etc.

[0037] Optionally, one approach to extracting entities and their relationships from character background data can be automated extraction using a pre-trained named entity recognition and relationship extraction model fine-tuned in the mythology and literature domains. Another approach can be semi-automated extraction based on a constructed mythology domain ontology and narrative logic template. This specification does not limit the scope of this approach.

[0038] For example, from the setting text of "virtual character A", the following triples are extracted through relation extraction: (virtual character A, father is, virtual character B), (virtual character A, competitor, virtual character D), (virtual character A competes with virtual character D, and the result is that virtual character A wins), (virtual character A wins and gives an olive tree to city-state A), (virtual character A accidentally kills, virtual character C), (accidentally killing virtual character C leads to virtual character A's grief and self-reflection).

[0039] Step 104 extracts the relationships between entities from the character background data, providing a data foundation for the subsequent construction of the background knowledge graph of the virtual character.

[0040] Step 106: Construct a background knowledge graph for the virtual character using entities as nodes and relationships as edges. The background knowledge graph includes at least one layer of knowledge graph, and the entity types of the entities in each layer of knowledge graph are different.

[0041] A node is a unit that represents an entity in a knowledge graph. For example, entities "virtual character A", "virtual character B", "the competition between virtual character A and virtual character D", "olive tree", and "virtual character C" can be created as independent nodes in the graph.

[0042] Edges are concrete links that instantiate relationships within the knowledge graph. Each edge uses the relationship as its type label and connects two entity nodes. For example, an edge is created from the "Virtual Character A" node to the "Virtual Character B" node, with the type label "Father is"; another edge is created from the "Virtual Character A" node to the "Competition between Virtual Character A and Virtual Character D" event node, then from that event node, an edge is created from the "Result is" node pointing to the "Virtual Character A wins" result node, and finally, from the "Virtual Character A wins" node, an edge is created from the "Gift" node pointing to the "Olive Tree" node and the "City A" node.

[0043] Entity types are classifications of entities based on the knowledge dimensions of virtual characters. For example, entity types include character-level entities, event-level entities, personality-level entities, and item-level entities.

[0044] At least one layer of the knowledge graph is a sub-graph divided according to entity type, and nodes between different layers are connected by cross-layer edges. For example, the person layer knowledge graph contains all person nodes and their relationships, the event layer knowledge graph contains all event nodes and their temporal or causal relationships, and the personality layer knowledge graph contains all personality trait nodes and their inherent connections.

[0045] A knowledge graph is a directed attribute graph that integrates the nodes and edges mentioned above. It formally describes the concepts, entities, and complex relationships between them in the background world of virtual characters.

[0046] Optionally, one way to construct the background knowledge graph of a virtual character, using entities as nodes and relationships as edges, is to use a graph database for storage and retrieval. Another approach is to serialize the triplet data into a standard knowledge representation format file. This specification does not limit this approach.

[0047] Indicative Figure 2 This specification illustrates a schematic diagram of the structure of a multi-layered knowledge graph provided in one embodiment.

[0048] refer to Figure 2This knowledge graph comprises a role layer (role A, role B, role C, role D, role E), a personality layer (personality 1, personality 2, personality 3, personality 4, personality 5), and an event layer (event 1, event 2, event 3, event 4, event 5). Nodes (entities) in each layer are connected by cross-layer edges (dashed lines) to represent semantic relationships between nodes in different knowledge graphs. Examples include the subordinate relationship between a role and a personality, the participation relationship between a role and an event, and the causal influence relationship between events and personalities. Nodes within the same layer are connected by same-layer edges (solid lines) to represent logical relationships between entities within the same knowledge graph, such as character relationships in the role layer, temporal or causal relationships in the event layer, and complementary or progressive relationships in the personality layer. (Reference) Figure 2 Taking character E as an example, it is connected to characters A, B, and D respectively, indicating that character E has character connections with characters A, B, and D. Character E is connected to personality 4 and event 3, indicating that character E possesses personality 4 (such as bravery) and has experienced event 3.

[0049] For example, taking "Character A" as an example, in the character layer, the "Character A" node is connected to the "Character B" node via the "Father is" edge, to the "Character C" node via the "Collaborator" edge, and to the "Character D" node via the "Competitor" edge, forming a character relationship network. In the event layer, the "Character A's Birth" node is connected to the "Guardian God Competition" node via the "Preceded" edge, and the "Accidental Killing Event" node is connected to the "Punishment Event" node via the "Caused" edge, forming a chronological and causal chain of events. In the personality layer, the "Wisdom" node and the "Courage" node are connected via the "Complementary" edge, forming a network of personality traits. Between different layers of the knowledge graph, the "Character A" node is connected to the "Wisdom" node and the "Courage" node via the "Possesses these two personality traits" edge, indicating that it possesses both personality traits. The "Character A" node is connected to the "Guardian God Competition" node and the "Accidental Killing Event" node via the "Participation" edge, indicating that it experienced these key events. The "accidental killing incident" node is connected to the "grief" personality node via a "cause" edge, indicating that the incident caused the grief aspect of the personality. Through the organic combination of the above-mentioned same-layer and cross-layer edges, the multi-layer knowledge graph can clearly and conveniently depict the relationships, personality traits, and key experiences of virtual characters, as well as the complex interactions between the three.

[0050] Step 106 constructs a background knowledge graph of virtual characters by using entities as nodes and relationships as edges, providing a data foundation for the subsequent construction of a background knowledge base for virtual characters based on the background knowledge graph.

[0051] Step 108: Assign corresponding weight information to each layer of the knowledge graph to obtain a background knowledge graph containing weight information.

[0052] Weight information is an identifier (e.g., a numerical value) that represents the importance of each layer of the knowledge graph during the retrieval or generation process. For example, when training a character dialogue model, a weight of 0.3 can be set for the character layer knowledge graph, a weight of 0.5 for the event layer knowledge graph, and a weight of 0.2 for the personality layer knowledge graph. This allows the model to prioritize event layer knowledge, followed by interpersonal relationships, and finally personality traits when generating responses.

[0053] Optionally, one way to assign corresponding weight information to each layer of the knowledge graph is to assign values ​​based on expert experience in the role setting manual. Another way to assign corresponding weight information to each layer of the knowledge graph is to automatically learn the weights by analyzing the frequency of knowledge references in each layer of the knowledge graph from historical dialogue data. This specification does not limit this approach in the embodiments.

[0054] For example, in a dialogue scenario for “virtual character A”, the event layer weight is set to 0.6, the character layer weight to 0.3, and the personality layer weight to 0.1, based on the character’s characteristics.

[0055] Step 108 sets corresponding weight information for each layer of the knowledge graph to obtain a background knowledge graph containing weight information. This enables the subsequent retrieval process to prioritize returning the knowledge graph layer content most relevant to the current dialogue context based on the weight, avoiding mutual interference between knowledge in different layers of the knowledge graph and improving the accuracy of knowledge retrieval.

[0056] Step 110: Based on the background knowledge graph containing weight information, construct a background knowledge base for virtual characters. The background knowledge base is used to provide relevant background knowledge as the context for retrieval enhancement generation of the dialogue model for training virtual characters.

[0057] Background knowledge base is a knowledge storage and retrieval system that supports efficient semantic retrieval.

[0058] Retrieval-Augmented Generation (RAG) is a technique that retrieves relevant information from external knowledge sources during the inference or training process of generative models, and then uses this information as context input to generate more accurate and context-appropriate responses.

[0059] The context is the additional auxiliary information provided in the text sequence input to the generative model, besides the current problem.

[0060] Optionally, the background knowledge base is used to provide relevant background knowledge. One implementation of this as the context for enhancing the generation of dialogue models for training virtual characters can be that, during model training, for each training question (e.g., a user asks "Why do you always carry a shield?"), the most relevant knowledge fragments (e.g., "Virtual character A possesses a shield, which is a symbol of their authority and protection") are retrieved from the background knowledge base and concatenated with the question as background information before being input into the model, requiring the model to generate a response based on this. Another implementation can be that the training instructions explicitly require the model to refer to the retrieved knowledge fragments when generating the response. This specification does not limit this approach in the embodiments.

[0061] Optionally, one way to construct a background knowledge base for virtual characters based on a background knowledge graph containing weight information is to split the nodes and edges in the knowledge graph into independent vector sets layer by layer, assign a corresponding weight coefficient to each layer, and calculate weighted similarity during retrieval. Another way to construct a background knowledge base for virtual characters based on a background knowledge graph containing weight information is to jointly encode the weight information as part of the embedding vector when vectorizing knowledge fragments. This specification does not limit this approach in its embodiments.

[0062] For example, the knowledge graphs for the person layer, event layer, and personality layer are constructed as independent vector databases, storing corresponding weight values ​​of 0.3, 0.5, and 0.2, respectively. When a query is input, the similarity score with each layer's knowledge graph is calculated, and then the scores are multiplied by the corresponding layer's weight and summed. The Top-K results are returned in order of weighted total score, thus realizing weight-guided knowledge retrieval.

[0063] Step 110 constructs a background knowledge base for virtual characters based on a background knowledge graph containing weighted information. The background knowledge base provides relevant background knowledge as context for retrieval enhancement of the dialogue model for training virtual characters. It can inject accurate knowledge related to character settings, key experiences, and emotional motivations into the dialogue model, enabling the model not only to answer user questions but also to understand and generate responses that conform to the complex personality, historical background, and inner emotions of virtual characters, so that the responses of virtual characters are consistent with their character positioning.

[0064] In this embodiment, the following steps are taken: Background data of the virtual character is obtained; entities and relationships between entities are extracted from the background data; a background knowledge graph of the virtual character is constructed using entities as nodes and relationships as edges. The background knowledge graph includes at least one layer of knowledge graph, with different entity types in each layer; corresponding weight information is assigned to each layer of knowledge graph to obtain a background knowledge graph containing weight information; and a background knowledge base of the virtual character is constructed based on the background knowledge graph containing weight information. This background knowledge base provides relevant background knowledge as context for retrieval enhancement generation in training the dialogue model of the virtual character. It can transform the background knowledge of a character into a structured knowledge system rich in semantic logic and hierarchical entity weight information. As a reliable knowledge source in the retrieval enhancement generation process, it enables the dialogue model to selectively retrieve and learn the character background knowledge most relevant to the current context from different types of entities based on the weight information of each knowledge layer during the training phase. This avoids logical confusion or information overload caused by the mixing of knowledge dimensions. It also enables virtual characters to generate logically consistent, stylistically consistent dialogue content that matches the user's focus based on their own role positioning and the implicit emphasis in the user's expression. This solves the problems of virtual characters generating dialogue content that does not match their role positioning, has logical contradictions, and outputs responses that deviate from the user's expression focus due to the lack of background knowledge support, thus improving the immersion of users in the dialogue process with virtual characters.

[0065] In one optional embodiment of this specification, after step 102, the method further includes: Acquire user status data and quantify the status data to obtain at least one status category; Following step 108, the following is also included: Associating state categories with target edges in a background knowledge graph containing weight information yields a background knowledge graph that embeds state data and contains weight information. Here, a target edge is at least two edges that originate from the same node and are connected to different entities of the same type. Step 110 includes: Based on a background knowledge graph containing embedded state data and weight information, a background knowledge base for virtual characters is constructed. This background knowledge base provides relevant background knowledge as context for retrieval enhancement generation in training the dialogue model of the virtual characters.

[0066] Status data is a set of information that can characterize a user's current physiological state and / or personality traits. For example, physiological status data collected through biosensors (such as electroencephalograms, skin conductance responses, and heart rate variability), or personality trait data obtained through questionnaire assessments (such as psychological traits such as extraversion, neuroticism, and openness).

[0067] State categories are discrete labels obtained after quantifying and classifying state data, used to identify the user's state type under a specific dimension. For example, state categories corresponding to physiological state data may include "relaxed", "tense", "pleasant", and "tired", while state categories corresponding to personality trait data may include "extroverted", "introverted", "optimistic", and "cautious".

[0068] Optionally, one way to acquire and quantify user state data to obtain at least one state category is to collect the user's physiological signals in real time using biosensors and map the signals to a preset set of state categories using a pre-trained classification model. Another way to acquire and quantify user state data to obtain at least one state category is to obtain the user's personality trait data through questionnaire assessment and classify the state categories according to a preset scoring threshold. This specification does not limit the scope of this embodiment.

[0069] The target edge consists of at least two edges originating from the same node and connected to different entities of the same type. These edges are used to activate different relationship paths under different user states to achieve dynamic narrative. For example, Figure 3 This diagram illustrates a different structure of a multi-layered knowledge graph provided in one embodiment of this specification. (Reference) Figure 3 The knowledge graph includes a role layer (role A, role B, role C, role D, role E) and an event layer (event 1, event 2, event 3). The state categories include relaxed, tense, and happy. The target edge is a set of three edges that start from the "role A" node and connect to "event 1" (peace narrative), "event 2" (conflict narrative), and "event 3" (achievement narrative), respectively, and are associated with the three state categories of "relaxed", "tense", and "happy".

[0070] Optionally, one implementation of associating state categories with target edges in a background knowledge graph containing weight information is to add a state category attribute to each target edge, identifying the user state to which the edge applies. Another implementation of associating state categories with target edges in a background knowledge graph containing weight information is to configure a weight vector for the target edge, where each element corresponds to the activation intensity under different state categories. Yet another implementation of associating state categories with target edges in a background knowledge graph containing weight information is to embed the state category as metadata into the target edge. The embodiments in this specification do not limit this approach.

[0071] Optionally, one way to construct a background knowledge base for virtual characters based on a background knowledge graph containing embedded state data and weight information is to construct independent vector indexes for the knowledge fragments corresponding to the edges carrying state category metadata in the graph, and select the corresponding index for querying based on the current state category during retrieval. Another way to construct a background knowledge base for virtual characters based on a background knowledge graph containing embedded state data and weight information is to jointly encode the state category as part of the vector when vectorizing the knowledge fragments, thereby achieving state-aware semantic retrieval. This specification does not limit the scope of this embodiment.

[0072] For example, based on the background knowledge graph of "virtual character A", a three-layer structure of character layer, event layer, and personality layer is constructed. The "virtual character A" node is connected in the event layer to the event nodes "Playing with virtual character E" (associated with the state category "Relaxed"), "Competing with virtual character D" (associated with the state category "Tense"), and "Giving a birthday gift" (associated with the state category "Joyful"). When the system identifies the user as being in a "Tense" state, the retrieval logic prioritizes edges associated with the "Tense" category, recalling knowledge fragments related to the "Competing with virtual character D" event; when the user is in a "Relaxed" state, it prioritizes recalling knowledge fragments related to the "Playing with virtual character E" event, achieving the technical effect of dynamically adjusting the narrative content according to the user's state.

[0073] In this embodiment, user state data is acquired and quantified to obtain state categories. These categories are then associated with target edges in a background knowledge graph containing weight information. A background knowledge base is constructed based on this background knowledge graph, which embeds state data and includes weight information. This allows knowledge fragments in the knowledge base to be associated with user state categories. During subsequent retrieval, appropriate knowledge fragments are dynamically selected based on the user's current state, achieving state-aware knowledge retrieval and dynamic narrative. This enables virtual characters to output content that matches the user's state, further enhancing the user's immersion during the dialogue process.

[0074] It should be noted that while the aforementioned background knowledge graph can provide structured knowledge fragments related to the role, relying solely on it to generate the final natural language dialogue has the following inherent limitations: 1. Insufficient flexibility and generation capability of background knowledge graphs: Knowledge graphs are based on structured triples (entity-relationship-entity), which cannot, like humans or high-level language models, flexibly organize these facts into natural, fluent, emotional and role-appropriate complete paragraphs based on dialogue context, user emotions and complex intentions.

[0075] 2. Security, privacy, and cost issues exist: Although cutting-edge large language models have powerful contextual understanding and text generation capabilities, and can produce high-quality responses by combining the retrieval results of knowledge graphs, directly calling commercial large model APIs or deploying full-parameter large models will bring significant cost, data privacy, and security controllability issues.

[0076] Based on this, one embodiment of this specification provides a dialogue model training method, which uses the background knowledge base constructed by the aforementioned background knowledge graph to train a lightweight dialogue model, and uses low-rank adaptation technology to inject role background knowledge into the lightweight dialogue model. This achieves the goal of ensuring that the dialogue content accurately matches the role setting and has high expressiveness, while reducing the dependence on computing resources, improving response speed, and enhancing the controllability and data privacy security of the system.

[0077] Indicatively, Figure 4 A flowchart illustrating a dialogue model training method according to an embodiment of this specification is shown, including: Step 402: Obtain the sample dataset, which includes sample questions and labeled responses. The sample questions contain at least one type of entity and its corresponding weight information.

[0078] The sample dataset is a collection of paired data used to train virtual dialogue models. For example, a set of question-answer pairs specifically constructed to train a dialogue model for a virtual character "Virtual Character A".

[0079] The sample questions are natural language inquiries or conversational openings that a user might ask the virtual character. For example, "Why are you carrying a shield?", "What do you think of the virtual character E?", and "How does it feel to be the guardian of city-state A?".

[0080] The tagged responses are preset standard answers that correspond to the sample questions and strictly conform to the background setting, knowledge system, and language style of the virtual character. For example, the tagged response to "Why are you holding a shield?" could be: "This is the shield of God. It not only symbolizes my duty to protect, but also the symbol of authority I have held since birth, as recorded in the epic."

[0081] Optionally, one way to obtain a sample dataset is to filter out high-quality dialogue pairs from historical player-virtual character interaction logs of digital cultural products after noise reduction and anonymization. Another way to obtain a sample dataset is to automatically generate simulated question-and-answer pairs that conform to the character settings using templates or language models based on an existing background knowledge graph. Yet another way to obtain a sample dataset is for character writers or domain experts to manually write them according to a character setting manual. This specification does not limit the scope of this method.

[0082] For example, the sample dataset constructed for "virtual character A" contains one data point: the sample question is "Why did you win the competition against virtual character D?", and the corresponding labeled answer is "Because I gave olive trees, symbols of peace, to the citizens of city-state A, while virtual character D only gave salt springs. The people of city-state A chose peace, and I thus won." At the same time, this sample question is labeled with entity type and weight information; for example, the entity type is "event layer," and the weight is 0.8, indicating that the question focuses on inquiring about the character's event experiences.

[0083] Step 404: Input the sample question into the dialogue model of the virtual character, and retrieve the relevant background knowledge of the virtual character from the background knowledge base based on at least one type of entity and its corresponding weight information. The background knowledge base is constructed according to the above-mentioned method for constructing the character background knowledge base.

[0084] The concepts of virtual characters and background knowledge base have been described above and will not be repeated here.

[0085] Relevant background knowledge refers to one or more knowledge fragments retrieved from the background knowledge base that are semantically most relevant to the current sample question. These knowledge fragments originate from the background knowledge graph of the virtual character. For example, for the question "Why did you win the competition with virtual character D?", the retrieved relevant background knowledge might include knowledge fragments such as "virtual character A competes with virtual character D for the guardianship of city-state A", "virtual character A gives an olive tree", "virtual character D gives a salt spring", "the people of city-state A choose the olive tree", and "virtual character A wins and becomes the guardian".

[0086] Optionally, one implementation of retrieving relevant background knowledge of virtual characters from a background knowledge base based on at least one type of entity and its corresponding weight information can be to determine the priority knowledge layer for retrieval based on the weight information, calculate the semantic similarity between the sample question and the knowledge fragment within that layer, and return the Top-K fragments with the highest similarity. Another implementation of retrieving relevant background knowledge of virtual characters from a background knowledge base based on at least one type of entity and its corresponding weight information can be to perform a weighted retrieval based on entity type and weight, using the weight as a weighting coefficient for the retrieval results of each knowledge layer. This specification does not limit the scope of this implementation.

[0087] For example, regarding the sample question "Why did you win the competition against the virtual character D?", the system first identifies the entity type corresponding to this question as "Event Layer" with a weight of 0.8, and also identifies "Character Layer" with a weight of 0.2. The system prioritizes semantic retrieval at the Event Layer, retrieving event knowledge fragments related to "competition," while simultaneously retrieving a small amount of relevant character relationship knowledge from the Character Layer. Finally, the retrieval results from the Event Layer and Character Layer are merged according to their weighted proportions to form the final retrieval result.

[0088] Step 406: Using relevant background knowledge as context, generate predicted responses to the sample questions.

[0089] Context refers to the additional textual information provided to the dialogue model, in addition to the original question, during response generation to guide and constrain the generation process. In this step, context specifically refers to the retrieved and formatted relevant background knowledge.

[0090] The predicted response is the text output generated by the dialogue model after receiving a sample question and relevant background knowledge as input.

[0091] Optionally, one way to generate a predicted answer to a sample question using relevant background knowledge as context is to concatenate the retrieved relevant background knowledge text before the sample question in the format "Background Knowledge: [Knowledge Text]" to form the model's input prompt. Another approach is to use a specific instruction template to encapsulate the background knowledge and the question together, such as "Based on the following knowledge about [Role Name]: [Knowledge Text], please answer the question as [Role Name]: [Sample Question]". This specification does not limit the implementation of this approach.

[0092] For example, the three retrieved knowledge fragments are concatenated with a sample question to form the following input prompt: "Background knowledge: Event: City-state A's Guardian God Competition. Participants: Virtual Character A, Virtual Character D. Virtual Character A's gift: An olive tree, symbolizing peace and abundance. Competition result: The people of City-state A chose the olive tree, and Virtual Character A won, becoming the guardian god of City-state A. Question: Why were you able to win the competition against Virtual Character D?" This prompt is then input into the initial dialogue model, which generates a predicted response, such as: "Because I gave the olive tree, symbolizing wisdom and peace, which is the cornerstone of City-state A's future prosperity, I won the hearts of the people of City-state A and won the position of guardian."

[0093] Step 408: Calculate the loss value based on the predicted response and the labeled response.

[0094] The loss value is a numerical value used to quantify the degree of difference between the predicted response and the labeled response generated by the model. The smaller the loss value, the closer the predicted response is to the labeled response.

[0095] For example, the cross-entropy loss function is used to compare and calculate the predicted probability distribution of each word in the predicted response with the true distribution of the corresponding word in the tagged response, and the total loss value is obtained.

[0096] Step 410: Adjust the model parameters of the dialogue model based on the loss value to obtain the trained target dialogue model of the virtual character.

[0097] The model parameters are adjustable weights and / or biases that constitute the dialogue model.

[0098] Optionally, one implementation of adjusting the model parameters of the dialogue model based on the loss value can be to use stochastic gradient descent or a variant thereof, calculating the gradient based on the loss value and performing a full update on all model parameters. Another implementation of adjusting the model parameters of the dialogue model based on the loss value can be to use a parameter-efficient fine-tuning technique (such as LoRA) to update a small number of low-rank adapter parameters injected into the model while keeping the original pre-trained model parameters frozen. The embodiments in this specification do not limit this approach.

[0099] It should be noted that the aforementioned low-rank adapter can be trained based on mixed corpus information of different virtual characters, which can be used for rapid and personalized fine-tuning of different virtual characters. When fine-tuning for a target virtual character, only a few iterations of the general adapter need to be performed using the character's specific sample dataset to obtain a personalized adapter that highly fits the character's settings, significantly reducing training costs and data requirements.

[0100] For example, based on the calculated loss value, the gradients of the low-rank adapter parameters in the model are computed using the backpropagation algorithm, and these parameters are updated using an optimizer. After multiple rounds of iterative training, a target dialogue model that integrates knowledge specific to "virtual character A" and possesses its language style is obtained.

[0101] In this embodiment, a sample dataset is acquired, comprising sample questions and labeled responses. The sample questions contain at least one type of entity and its corresponding weight information. The sample questions are input into the dialogue model of the virtual character. Based on the at least one type of entity and its corresponding weight information, relevant background knowledge of the virtual character is retrieved from the background knowledge base. Using the relevant background knowledge as context, a predicted response to the sample question is generated. Based on the predicted response and the labeled response, a loss value is calculated. Based on the loss value, the model parameters of the dialogue model are adjusted to obtain a trained target dialogue model for the virtual character. This model can deeply integrate the background knowledge of the character during the training phase of the dialogue model and associate it with the accurate character settings from the background knowledge base. By introducing entity types and their corresponding weights, the model can selectively retrieve relevant knowledge from the corresponding knowledge layer during training, based on the topic dimension emphasized by the sample question. This guides the model to learn which type of role background knowledge should be emphasized under which topic. As a result, when generating dialogue content, the dialogue model can not only deeply understand and follow the complete knowledge and internal logic of a specific virtual role, but also accurately identify the implicit concerns in the user's question and call on the matching knowledge dimension to answer. This avoids irrelevant answers or mixed content caused by knowledge dimension mismatch. The goal is to achieve a high degree of consistency between the dialogue content generated by the target dialogue model and the role positioning of the virtual role in terms of factuality, logical consistency, unique style, and emotional authenticity. This solves the problems of empty dialogue content, inconsistency with the role positioning, and output deviating from the user's concerns caused by the lack of role knowledge.

[0102] In one optional embodiment of this specification, the sample dataset further includes the state category corresponding to the sample problem; Step 404 includes: inputting a sample question into the dialogue model of the virtual character, and retrieving relevant background knowledge of the virtual character from the background knowledge base based on the state category corresponding to the sample question, at least one type of entity and its corresponding weight information, wherein the background knowledge base is constructed according to the above-mentioned method for constructing a character background knowledge base.

[0103] Optionally, one approach to retrieving relevant background knowledge of a virtual character from a background knowledge base based on the state category corresponding to the sample question, at least one type of entity, and its corresponding weight information could be to first determine the applicable set of target edges based on the state category, and then perform semantic retrieval within the corresponding knowledge layer based on the entity type and its weight information, returning the knowledge fragment that matches the state category and has the highest semantic similarity to the sample question. Another approach could be to construct a state-entity joint retrieval vector, concatenating or weighting the state category encoding, entity type encoding, and sample question vector, and then performing a joint retrieval in the knowledge base. This specification does not limit the scope of this approach in its embodiments.

[0104] For example, regarding the sample question "Why did you win the competition against virtual character D?", the corresponding state category is "Tense," and the entity types are "Event Layer" with a weight of 0.8 and "Character Layer" with a weight of 0.2. The system first filters target edges associated with the "Tense" state category from the background knowledge base, such as the edge connecting the "Virtual Character A" node to the "Compete against Virtual Character D" event node. Then, within the knowledge scope associated with this target edge, it prioritizes retrieving knowledge fragments related to "Competition" from the Event Layer based on the entity type weight, while simultaneously retrieving relevant character relationship knowledge from the Character Layer. Finally, the retrieval results are output as relevant background knowledge.

[0105] In the embodiments of this specification, by acquiring a sample dataset containing state categories, the state category, entity type, and weight information corresponding to the sample question are used as the retrieval basis during retrieval. Adaptable background knowledge is retrieved from the background knowledge base embedded in the state data. This enables the model to learn during the training phase which knowledge dimensions should be emphasized in specific user states. The model can not only identify the implicit concerns in user questions but also perceive the user's current state and dynamically adjust the knowledge retrieval strategy according to the state category, selecting the knowledge fragment that best matches the current state as the context for dialogue generation. Thus, the trained target dialogue model, during inference, can generate personalized dialogue content that fits the role positioning, adapts to the user's current state, and accurately responds to the user's concerns based on the real-time collected user state and question content, further enhancing the immersive experience of the user's dialogue with the virtual character.

[0106] In one optional embodiment of this specification, the dialogue model includes an attention module, which includes a low-rank linear layer; The model parameters of the dialogue model are adjusted based on the loss value to obtain the trained target dialogue model of the virtual character, including: Based on the loss value, the parameters of the low-rank linear layer of the attention module in the dialogue model are adjusted to obtain the trained target dialogue model of the virtual character.

[0107] The attention module is a core component in dialogue models that implements the self-attention mechanism. It is responsible for calculating the association weights between different positions in the input sequence to capture long-distance dependencies and contextual semantics. For example, in a pre-trained large language model based on the Transformer architecture, each layer contains a multi-head self-attention module.

[0108] The low-rank linear layer is a trainable parameter adaptation layer injected in the form of low-rank decomposition, based on the original linear projection layers (such as query, key, value, and output projection layers) of the attention module. This low-rank linear layer consists of a pair of low-rank matrices, which work in parallel with the frozen original weight matrix to jointly determine the forward propagation output of the attention module.

[0109] Optionally, one implementation of adjusting the parameters of the low-rank linear layer of the attention module in the dialogue model based on the loss value to obtain the trained target dialogue model of the virtual character can be: during the training iteration, keep all original parameters of the dialogue model except for the low-rank linear layer in a frozen state, calculate only the gradient of the low-rank linear layer parameters with respect to the loss value, and use the optimizer to update these parameters. Another implementation of adjusting the parameters of the low-rank linear layer of the attention module in the dialogue model based on the loss value to obtain the trained target dialogue model of the virtual character can be: in the early stage of training, only update the parameters of the low-rank linear layer, and in the later stage of training, jointly fine-tune some of the original model parameters with a very low learning rate. The embodiments in this specification do not limit this approach.

[0110] For example, for the initial dialogue model, in the self-attention module of each Transformer block, low-rank adapters with rank r=8 are injected into the four linear projection layers: Query, Key, Value, and Output. During training, the optimizer only updates the parameters of these newly added low-rank matrices, while the original parameters of the model remain unchanged. Through multiple rounds of training based on role-specific sample data, the low-rank linear layers gradually learn the knowledge and style patterns required to adapt general language capabilities to the specific role "Virtual Role A". During training, the parameters of the initial dialogue model are frozen, preserving its basic capabilities in general language understanding, common-sense reasoning, etc., and learning role-specific differentiated knowledge only through a small number of newly added parameters, preventing catastrophic forgetting caused by overfitting to role data. Each virtual role's dedicated low-rank adapter can be stored independently as a lightweight weight file, which can be dynamically loaded according to the currently interacting virtual role during deployment, without loading a complete model copy, laying the foundation for customizing dedicated dialogue models for massive numbers of virtual roles. When it is necessary to optimize the dialogue performance of a certain role, it is only necessary to use the newly added sample data to incrementally fine-tune the low-rank adapter of the role and generate a new adapter weight file. This allows for hot updates during service runtime, enabling the target dialogue model to generate dialogue content that is highly consistent with the role's own positioning while maintaining efficient inference speed and low resource consumption.

[0111] In the embodiments described in this specification, by adjusting the parameters of the low-rank linear layer of the attention module in the dialogue model based on the loss value, a trained target dialogue model for the virtual character is obtained. This allows a general pre-trained dialogue model to quickly learn and internalize the background knowledge, language style, and response logic of a specific virtual character with minimal increase in storage and computational overhead, all achieved by optimizing a small number of newly added low-rank parameters. Furthermore, it reduces training costs and enables the efficient generation of independent, non-interfering, lightweight model copies for a large number of different virtual characters.

[0112] Indicatively, Figure 5 A flowchart of a role control method provided in one embodiment of this specification is shown, including: Step 502: Receive the target question sent by the front end.

[0113] The front end is the application interface or client program that interacts directly with the user. For example, the user client, web application interface, or mobile application of a digital cultural product.

[0114] The target question is data (such as voice or text) that carries specific semantics and is entered by the user through the front-end interface. For example, a user might enter the following in the dialogue interface of a virtual character "Virtual Character A": "What do you think is the greatest virtue of mankind?"

[0115] Optionally, one implementation of receiving the target question sent by the frontend is to receive a JSON-formatted data packet submitted by the frontend via the WebSocket protocol, containing user input text. Another implementation of receiving the target question sent by the frontend is to receive a structured request via a remote procedure call framework. Yet another implementation of receiving the target question sent by the frontend is to consume user request events pushed by the frontend service from a message queue. This specification does not limit the scope of these implementations.

[0116] For example, a user types a question in the interaction interface with "virtual character A" and clicks send. The front-end encapsulates the question into a JSON object {"role_id": "athena", "query": "As the goddess of wisdom, what do you think is the greatest virtue of mankind?", "session_id": "xyz123"}, and sends it to the back-end service interface via an HTTPS POST request. The back-end service's request processing module receives and parses the JSON object, extracting the target question text.

[0117] Step 504: Analyze the target problem to obtain the entity types of the entities in the target problem and their corresponding weight information.

[0118] Optionally, one approach to analyzing the target question and obtaining the entity types and corresponding weights of entities within it can be based on a pre-trained text classification model. This model performs semantic analysis on the target question, identifies the mentioned entities and their respective knowledge layers, and calculates weights based on the semantic importance of the entities in the question or their relevance to the core character setting. For example, a neural network classifier can be used to map the target question to a preset entity type distribution and output the confidence score of each type as a weight. Another approach is to extract keywords corresponding to entities in the character's background knowledge graph from the target question through keyword matching and rule parsing, and determine the entity type and its weight based on a preset mapping relationship. For example, if the question contains keywords such as "why fight" or "how to win," it is determined to be an event-layer entity with a weight of 0.8. This specification does not limit the scope of this approach in the embodiments.

[0119] For example, regarding the target question "As the goddess of wisdom, what do you consider to be the greatest virtue of humankind?", the analysis module identifies "goddess of wisdom" as referring to the personality trait of "virtual character A", and "virtue" as referring to a personality layer entity. Therefore, the entity type is determined to be "personality layer", with a weight of 0.9. Simultaneously, it identifies that "humankind" implicitly refers to the event of "creating a human with virtual character E", associating it with the "event layer", with a weight of 0.3. The final output entity type and weight information is: {"personality layer": 0.9, "event layer": 0.3}.

[0120] Step 506: Input the target question, the entity types of the entities in the target question, and their corresponding weight information into the target dialogue model of the virtual character, so that the target dialogue model of the virtual character can reason about the target question based on the entity types of the entities and their corresponding weight information, and generate the target response. The target dialogue model of the virtual character is trained by the dialogue model training method described above.

[0121] The process involves reasoning about the target question, receiving the target question as input, and then performing forward computation through an internal multi-layer neural network to gradually generate a sequence of natural language responses that conform to the character settings.

[0122] Optionally, the target dialogue model infers the target question based on the entity type and its corresponding weight information to generate the target response. One implementation method is to concatenate the target question with the entity type and weight information and input it into the model. During the generation process, the model prioritizes extracting information from the knowledge internalized in the corresponding knowledge layer according to the weight information. Another implementation method is to dynamically adjust the attention mechanism based on the weight information when generating the response, so that the model pays more attention to the internal representations related to the high-weight knowledge layer during the decoding process. The embodiments in this specification do not limit this approach.

[0123] For example, the target question "As the goddess of wisdom, what do you consider to be the greatest virtue of mankind?" is concatenated with entity type and weight information {"Personality Layer": 0.9, "Event Layer": 0.3} to form the input sequence. When generating the response, the target dialogue model prioritizes extracting content related to "wisdom" and "justice" from internalized personality trait knowledge based on the higher weight of the personality layer. Simultaneously, based on the weight of the event layer, it appropriately references the connotation of "creation" embodied in the event "establishing a city-state with the virtual character E". The final target response is generated as follows: "While wisdom guides the way, the most precious virtue of mankind is prudence. As I taught heroes: courage without thought is recklessness, wisdom without just judgment is sophistry. Prudence is the bridge connecting wisdom and action; it enables mankind to choose peace and long-term prosperity for its city-state, just as the citizens of city-state A chose the olive tree."

[0124] Step 508: Output the target response to the front end.

[0125] Optionally, one way to output the target response to the front end is to directly push the target response text to the text display area of ​​the front end's graphical user interface. For example, the text can be displayed as a bubble dialog box in a chat window. Another way is to combine the front end's preset virtual character animation and lip-sync technology to convert the target response text into speech and drive the character model to broadcast it. For example, speech synthesis technology can be used to generate corresponding audio, while simultaneously driving the digital human character's lip movements, facial expressions, and body movements to match the speech content. Yet another way to output the target response to the front end is to trigger specific interactive animations, effects, or interface feedback preset by the front end based on the semantics and emotional tendency of the target response. For example, if the response content contains the key element "giving an olive tree," the front end interface can synchronously play a short animation of a character holding an olive branch or display a light effect of an olive tree pattern. This specification does not limit this approach.

[0126] For example, the backend service encapsulates the generated target response into response data and returns it to the frontend. After receiving the response, the frontend presents the response text to the user in a visual or auditory form through its graphical interface or speech synthesis module, completing one interaction loop.

[0127] In this embodiment, the system receives a target question sent from the front end; it then uses a target dialogue model of a virtual character to reason about the target question and generate a target response. The target dialogue model of the virtual character is trained using the aforementioned dialogue model training method. Outputting the target response to the front end ensures that the response generated in each round of interaction is based on the virtual character's background knowledge graph and includes personality traits, values, and language style consistent with the virtual character's positioning. By introducing entity type and weight information, the system can accurately identify the implicit dimensions of concern in the user's question during reasoning (e.g., whether the user is concerned about the character's personality traits, historical events, or character relationships). Based on the weights, the system guides the model to prioritize extracting and organizing information from the content internalized in the corresponding knowledge dimensions. This ensures that the generated response accurately addresses the user's concerns, avoiding irrelevant or mixed-content responses due to knowledge dimension mismatch. This allows users to obtain responses in digital cultural products that align with the virtual character's positioning and background knowledge, and fit their own expression focus, thus enhancing user immersion.

[0128] In one optional embodiment of this specification, step 502 further includes: Collect user status data; Analyze the state data to obtain the state category corresponding to the state data.

[0129] Step 506 includes: inputting the state category, target question, entity type of the entity in the target question and its corresponding weight information into the target dialogue model of the virtual character, so that the target dialogue model of the virtual character can reason about the target question based on the state category, entity type of the entity and its corresponding weight information, and generate a target response. The target dialogue model of the virtual character is trained by the dialogue model training method described above.

[0130] Optionally, one way to collect user status data is to collect the user's physiological signals in real time using biosensors, including at least one of electroencephalogram (EEG) acquisition devices, skin conductance sensors, and heart rate monitoring devices. Another way is to collect user questionnaire feedback or behavioral data through a front-end interactive interface to infer the user's personality traits. This specification does not limit this approach.

[0131] Optionally, one way to analyze state data and obtain the corresponding state categories is to use a pre-trained classification model to extract and classify features from real-time collected physiological signals, mapping continuous signals to discrete state categories, such as "relaxed," "tense," "pleasant," and "fatigued." Another approach is to obtain user personality trait data through questionnaires and classify users into state categories such as "extroverted," "introverted," "optimistic," and "cautious" based on preset scoring thresholds. This specification does not limit the scope of this approach.

[0132] For example, the system performs a fast Fourier transform on the acquired EEG signals, extracts the power spectral density features of alpha, beta, and theta waves, inputs them into a pre-trained support vector machine classifier, and outputs the current user state category as "nervous".

[0133] Optionally, the target dialogue model infers the target question based on state category, entity type, and corresponding weight information to generate the target response. One implementation involves concatenating the state category, entity type, and weight information with the target question and inputting the result into the model. During the generation process, the model prioritizes extracting information from knowledge edges associated with the state category and organizes it from the knowledge internalized in the corresponding knowledge layer based on the weight information. Another implementation involves the model dynamically adjusting the retrieval strategy based on the state category when generating the response, retrieving knowledge fragments matching the state category from the background knowledge base, and then fusing them with the entity type weights to generate the response. This specification does not limit the implementation of this approach.

[0134] For example, the user state category "Tense", entity type, and weight information {"Event Layer": 0.8, "Character Layer": 0.2} are concatenated with the target question "Why did you win the competition against the virtual character D?" to form the input sequence. Based on the state category "Tense", the target dialogue model prioritizes extracting narrative content related to "competition" and "victory" from knowledge edges associated with the "Tense" state category; simultaneously, based on the entity type weights, it primarily extracts details related to "competition" from the event layer knowledge, supplemented by the competitive relationship of "virtual character D" from the character layer knowledge. The final target response is generated as follows: "It was a fierce contest! I competed with virtual character D for the right to protect city-state A. I gave him an olive tree, a symbol of peace and abundance, while virtual character D only gave him salt springs. The people of city-state A chose hope and life, therefore I was declared the winner."

[0135] In this embodiment, user state data is collected and analyzed to obtain state categories. These categories, along with the target question, entity type, and weight information, are input into the target dialogue model. The model then infers and generates a target response based on the state category, entity type, and weight information. This allows the virtual character to not only identify the implicit concerns in the user's question but also perceive the user's current real-time state and dynamically adjust its narrative style and content emphasis according to the state category. This enables the virtual character to interact with the user in a more empathetic way, generating responses that are consistent with its role, adaptable to the user's current state, and accurately address the user's concerns, thus enhancing the immersive experience of the dialogue between the user and the virtual character.

[0136] In one optional embodiment of this specification, the method further includes: Receive control commands for virtual characters sent from the front end; The control commands are input into the target motion control model to obtain the animation sequence of the virtual character; Render the animation sequence to the front end.

[0137] Control commands are signals or instructions triggered by the user or system that drive virtual characters to perform specific actions or exhibit specific behaviors. For example, a user clicking a "greeting" button, a "express agreement" command automatically generated by the system based on the dialogue content, or a "move to a specified location" command triggered by game logic.

[0138] The target motion control model is a model that is trained on the initial motion control model and can generate animation sequences that conform to the behavior logic of the virtual character according to user instructions. It receives control instructions and environmental states as input, performs internal logic calculations, and outputs animation sequences that drive the body movements of the virtual character.

[0139] Optionally, one way to construct the target action control model is by manually arranging it based on preset rules and state machines. Another way to construct the target action control model is by using a hybrid architecture that combines behavior trees and finite state machines. This specification does not limit the specific approach used in the embodiments.

[0140] An animation sequence for a virtual character is a collection of multiple animation sub-sequences of the virtual character arranged in chronological order.

[0141] For example, after a user interacts with the virtual character "Virtual Character A" and receives a profound response about "virtue," they click the "appreciation" emoticon icon on the interface. The front-end then sends a control command {"Action Type": "Express Appreciation"} to the back-end. The back-end inputs this command into a pre-built target action control model for "Virtual Character A." After the model makes a decision, it outputs an animation sequence identifier, such as {"Standing in contemplation," "Slowly nodding," "Gentle smile"}. The back-end returns this sequence to the front-end, and the front-end graphics engine plays these three animation sub-sequences sequentially, causing the "Virtual Character A" on the screen to perform a series of actions: standing in contemplation, slowly nodding, and showing a gentle smile, thus reinforcing the emotional expression of "approval and satisfaction" in a non-verbal way.

[0142] In this embodiment, control commands for a virtual character are received from the front end; these commands are input into a target motion control model to obtain an animation sequence for the virtual character; and the animation sequence is rendered to the front end. This allows for the combination of dialogue and actions of the virtual character, enhancing the character's personality and emotional expression through actions, thereby further improving the user experience.

[0143] In one optional embodiment of this specification, before inputting control commands into the target motion control model to obtain the animation sequence of the virtual character, the method further includes: Construct multiple animation subsequences for the virtual character; Determine the priority, relevance, and transformation relationship between each animation subsequence, and determine multiple behavior levels based on priority and relevance. The behavior level includes a parent behavior level and a child behavior level. The parent behavior level consists of at least one child behavior level, and the child behavior level consists of at least one animation subsequence. Construct a behavior tree using the parent behavior hierarchy as the selection node and / or sequence node, the conditions executed by the parent behavior hierarchy as the condition node, and the animation sub-sequence mappings in the child behavior hierarchy as the execution node; A state machine is constructed using each animation subsequence in the same sub-behavior level as a state node and the transition relationship between each animation subsequence as an edge. By associating the behavior tree with the state machine, an initial motion control model is obtained; The initial motion control model is trained to obtain the target motion control model.

[0144] An animation subsequence is animation data representing a basic unit of action of a virtual character. For example, "walking loop", "waving greeting", or "shielding defense".

[0145] Optionally, one way to construct multiple animation sub-sequences of a virtual character is to export pre-made animation clip files from 3D animation software. Another way to construct multiple animation sub-sequences of a virtual character is to record and segment live performance data using motion capture equipment. This specification does not limit the scope of this approach.

[0146] Priority is a rule that determines the order in which each animation subsequence is executed. For example, the "being hit" animation has a higher priority than the "walking" animation to ensure that the character reacts immediately when attacked.

[0147] Relevance refers to the degree of logical or functional connection between different animation subsequences, and is used for behavior clustering and hierarchical division. For example, "walking fast," "running," and "dodging" have high relevance in the "movement" dimension.

[0148] The transition relationship is a logical rule that determines whether each animation subsequence can be switched and the conditions required for switching. For example, the condition for transitioning from the "idle" state to the "walking" state is "receiving a movement command", while the condition for transitioning from the "attack" state to the "hit" state is "collision detected and hit".

[0149] The behavioral hierarchy is a logical structure formed by organizing the behaviors of virtual characters in layers. In this structure, upper-level behavioral logic can be implemented by calling or combining lower-level behavioral logic, thus forming a logical mapping relationship from abstract goals to specific actions.

[0150] The parent behavior hierarchy represents a higher-level behavior that indicates a composite goal or abstract task within the behavior hierarchy. Examples include "combat," "movement," and "social interaction."

[0151] A sub-behavior hierarchy consists of lower-level behaviors that are specific components or implementation steps of a parent behavior hierarchy. For example, "battle" can be composed of sub-behavior hierarchies such as "approaching the enemy," "attacking," and "defending"; "attack" can be composed of animation sub-sequences such as "raising the sword," "slashing," and "sheathing the sword."

[0152] Optionally, one approach to determining the priority, relevance, and transition relationships between animation subsequences can be done manually based on the animator's domain knowledge and design documents. Another approach can be based on automatic learning through statistical analysis of a large amount of character behavior demonstration data. This specification does not limit this approach in its embodiments.

[0153] Optionally, one approach to determining multiple behavioral levels based on priority and relevance is to use a hierarchical clustering algorithm to automatically group and hierarchically divide the animation subsequences. Another approach is to manually classify and specify levels based on a preset behavioral taxonomy framework. This specification does not limit this approach in the embodiments.

[0154] The selection node is a type of control node in the behavior tree, which selects one of its child nodes to execute according to a preset strategy (such as priority order).

[0155] A sequence node is a type of control node in a behavior tree. It executes all its child nodes sequentially, and returns success only when all child nodes have been successfully executed.

[0156] A condition node is a type of leaf node in a behavior tree. It does not perform any action but is only used to evaluate whether a certain logical condition is true (such as "Is the enemy in sight?").

[0157] An execution node is a leaf node in the behavior tree. It is the endpoint of behavior decision-making and is used to trigger specific actions or state transition instructions (such as "play attack animation").

[0158] Behavior trees are tree-like data structures used to model the decision-making logic of virtual characters. They define complex, interruptible, and reusable behavioral patterns through combinations of control nodes, condition nodes, and execution nodes.

[0159] A state machine is a mathematical model used to manage the animation states and transitions of virtual characters. State nodes represent specific animation subsequences, and edges represent possible transitions and triggering conditions between states.

[0160] A state node is a node in a state machine that represents a specific animation state or sub-state of a virtual character.

[0161] The initial motion control model is an unoptimized motion control model composed of behavior trees and state mechanisms.

[0162] The target motion control model is the final motion control model that, after training or optimization, can stably, smoothly, and reasonably generate animation sequences of virtual characters based on control commands.

[0163] Optionally, one way to associate the behavior tree with the state machine to obtain the initial motion control model is to configure the output of the execution node in the behavior tree as an event or parameter that triggers a specific state transition in the state machine. Another way to associate the behavior tree with the state machine to obtain the initial motion control model is to set up a dedicated "command state" in the state machine to receive instructions from the behavior tree, which then dispatches instructions to specific animation states. This specification does not limit the scope of this embodiment.

[0164] Optionally, one way to train the initial action control model to obtain the target action control model is through imitation learning, using action sequence data demonstrated by experts to optimize the node selection strategy and state machine transition parameters in the behavior tree. Another way to train the initial action control model to obtain the target action control model is through reinforcement learning, allowing the model to automatically adjust its decision-making logic based on feedback reward signals during interaction with the environment. The embodiments in this specification do not limit this approach.

[0165] For example, a motion control model is constructed for the virtual character "Virtual Character A". First, the animator provides multiple animation sub-sequences, such as "Shield Waiting", "Shield Walking", "Shield Defense", "Spear Thrust", "Casting Divine Spell", "Standing Majestic", "Nodding in Approval", and "Sad Expression". Logically, "Shield Defense" is determined to have the highest priority, while "Being Hit" can interrupt most actions. The sub-sequences are clustered by functional relevance to form a behavior hierarchy: the top-level parent behaviors are "Combat Mode" and "Peace Mode". "Combat Mode" contains the sub-behaviors "Defense" and "Attack". "Defense" maps to the animation sub-sequence "Shield Defense", and "Attack" is further decomposed into "Melee Attack" and "Ranged Attack". Next, a behavior tree is constructed: the root node is the selection node, choosing between "Combat" and "Peace". The "Combat" sequence node contains the condition node "Enemy Close?", which, if true, triggers "Melee Attack"; otherwise, it triggers "Ranged Attack". The execution node is mapped to a specific animation sub-sequence. Simultaneously, a state machine is constructed for the "melee attack" sub-behavior, with state nodes including "ready," "thrust," and "retreat," and the transition relationships are driven by input commands and animation completion events. Finally, the "melee attack" execution node of the behavior tree is associated with the start event of the state machine. By allowing the model to fight against "monsters" in a simulated environment, reinforcement learning is used to optimize its strategy for selecting attack timing and defensive responses, thereby training a target action control model capable of coping with various combat situations.

[0166] In this embodiment, multiple animation sub-sequences of a virtual character are constructed; the priority, relevance, and transformation relationships between each animation sub-sequence are determined, and multiple behavior levels are determined based on the priority and relevance; a behavior tree is constructed using the parent behavior level as the selection node and / or sequence node, the execution condition of the parent behavior level as the condition node, and the animation sub-sequences in the sub-behavior level as the execution node; a state machine is constructed using each animation sub-sequence in the same sub-behavior level as the state node and the transformation relationships between each animation sub-sequence as the edges; and the behavior tree and the state machine are associated to obtain the initial motion control model. By training the initial motion control model, a target motion control model is obtained. This model can construct a motion control model that has both intelligent decision-making capabilities and delicate and smooth motion execution capabilities. The model can adaptively generate animation sequences that conform to the character's identity, current context, and user instructions, thereby achieving highly realistic, responsive, and expressive virtual character behavior in digital cultural products.

[0167] In one optional embodiment of this specification, constructing multiple animation sub-sequences of a virtual character includes: Animation capture is performed on virtual characters to obtain their motion skeletal features; Based on motion skeleton features, multiple animation subsequences of virtual characters are generated.

[0168] Animation capture is the process of recording motion data of real people through sensors and mapping it to the skeletal model of virtual characters.

[0169] Motion skeleton features are a set of data (such as position and orientation) describing the changes of a virtual character's skeleton in three-dimensional space over time.

[0170] Optionally, one way to perform motion capture on a virtual character and obtain its skeletal features is to use an optical motion capture system that tracks the movement of marked points on the performer's body using multiple high-speed cameras. Another way to perform motion capture on a virtual character and obtain its skeletal features is to use an inertial motion capture system that measures the performer's limb movement data using inertial sensors worn on the performer's body. This specification does not limit the scope of this method.

[0171] Optionally, one approach to generating multiple animation sub-sequences of a virtual character based on motion skeletal features involves segmenting, cleaning, and redirecting the original capture data according to the motion intent, generating independent animation clip files. Another approach to generating multiple animation sub-sequences of a virtual character based on motion graph features involves analyzing and recombining the capture data using motion graph technology to generate a library of smoothly transitionable animation clips. This specification does not limit the scope of this approach.

[0172] For example, to create the combat stance of the virtual character "Virtual Character A", a martial arts performer was invited to wear an optical motion capture suit and perform a series of actions including spear thrusting, shield blocking, standing majestically, and tactical movement. The system recorded the motion trajectory data of key skeletal points throughout the performer's body. Animators then imported this raw data into 3D software, adapted it to the skeletal model of "Virtual Character A", and, based on the start and end points and completeness of the actions, generated multiple independent animation sub-sequence files such as "Spear Thrust_01", "Shield Defense_Loop", and "Majestic Standing_Idle".

[0173] In the embodiments of this specification, motion skeletal features of virtual characters are obtained by motion capture of virtual characters; based on the motion skeletal features, multiple animation sub-sequences of virtual characters are generated, which can provide realistic and expressive motion materials for virtual characters and lay a data foundation for constructing natural and smooth character animation behavior.

[0174] In one optional embodiment of this specification, before inputting control commands into the target motion control model to obtain the animation sequence of the virtual character, the method further includes: Obtain environmental data of the virtual character; The control commands are input into the target motion control model to obtain the animation sequence of the virtual character, including: The control commands and environmental data are input into the target action control model. Based on the control commands and environmental data, the model traverses each node of the behavior tree to generate behavior decision commands. Then, the model generates the animation sequence of the virtual character based on the behavior decision commands through the state machine.

[0175] Environmental data is a set of attributes describing the entities in the virtual space where the virtual character is located. For example, the position and state of other characters in the scene, the attributes of interactive objects, terrain features, current time or plot stage markers, etc.

[0176] Optionally, one way to obtain environmental data of a virtual character is through real-time querying via an application programming interface (API) provided by a game engine or virtual world simulator. Another way to obtain environmental data of a virtual character is by subscribing to relevant data updates from a shared world state database or event bus. This specification does not limit this approach.

[0177] Decision instructions are commands that instruct the state machine to execute specific animation state transitions or play sequences.

[0178] For example, the virtual character "Virtual Character A" receives a control command to "move to point A". Simultaneously, the system acquires current environmental data: an obstacle, a "collapsed stone pillar," exists on the path ahead, and an enemy character, "Medusa," is detected nearby. The behavior tree of the target action control model, upon receiving the command and environmental data, begins traversal: the root selection node evaluates the priority between "movement" and "combat." Since "Medusa" has entered the detection range, the condition node "Enemy detected?" is met, thus selecting the "combat" branch. Under the "combat" sequence node, further environmental data such as "enemy distance" and "obstacle position" are used to generate a "ranged attack" behavior decision command (instead of "melee movement attack"). This decision command is sent to the state machine, which then switches from the current "walking" state to the "cast divine spell" animation state and plays the corresponding "ranged attack" animation sequence, while the character's position adaptively adjusts to avoid obstacles.

[0179] This embodiment acquires environmental data of the virtual character; inputs control commands and environmental data into the target action control model; and, based on the control commands and environmental data, traverses each node of the behavior tree to generate behavior decision commands. Then, a state machine generates an animation sequence for the virtual character based on these behavior decision commands. This enables the virtual character's action generation to possess environmental awareness and contextual understanding capabilities, achieving intelligent behavior decision-making. The model output is no longer a mechanical command mapping, but rather an optimal action response based on real-time perception of the virtual world, conforming to logic and dynamically adapting, thus improving the rationality and intelligence of the virtual character's behavior and enhancing the user experience.

[0180] In one optional embodiment of this specification, the virtual character includes a first virtual character and a second virtual character, and the animation sequence of the virtual character includes the animation sequence of the first virtual character; After inputting control commands into the target motion control model to obtain the animation sequence of the virtual character, the process also includes: Obtain the model correlation degree between the first virtual character and the second virtual character; Based on the model correlation and the animation sequence of the first virtual character, the animation sequence corresponding to the second virtual character is generated.

[0181] The first virtual character is a reference character that already has a mature motion control model. For example, a virtual character "Virtual Character A" that has been finely tuned.

[0182] The second virtual character is the target character whose animation sequence needs to be generated or optimized. For example, a virtual character "Virtual Character F" belonging to the same mythological system but which has not yet been fine-tuned.

[0183] Model correlation is a quantitative indicator that represents the degree of similarity between two virtual characters in terms of skeletal structure, animation style, behavioral logic, or the reusability of action resources.

[0184] Optionally, one way to obtain the model correlation degree between the first virtual character and the second virtual character is to calculate it based on the topological similarity of the skeletal structures of the two characters. Another way to obtain the model correlation degree between the first virtual character and the second virtual character is to measure it based on the distance between the existing key animation sequences of the two characters in the motion feature space. This specification does not limit this approach in the embodiments.

[0185] Optionally, one implementation of generating an animation sequence for a second virtual character based on model correlation and the animation sequence of the first virtual character can be achieved by directly adapting the animation sequence data of the first virtual character to the second virtual character using skeletal redirection technology when the model correlation is higher than a threshold. Another implementation of generating an animation sequence for a second virtual character based on model correlation and the animation sequence of the first virtual character can be achieved by using the animation sequence of the first virtual character as a reference sample and generating a new animation sequence that conforms to the characteristics of the second virtual character through a motion style transfer algorithm. This specification does not limit the scope of this implementation.

[0186] For example, in digital cultural products, a comprehensive motion library and motion control model have already been built for "virtual character A". Now, a "drawing the bow and shooting an arrow" animation needs to be quickly generated for a new character, "virtual character F" (the goddess of the hunt). The system calculates the correlation between the two models; since both are female deities with similar skeletal proportions, the correlation score is high. The system then uses the "spear throwing" animation sequence of "virtual character A" as a base, and through motion redirection and style adjustment (such as adjusting the throwing action's force posture to a more stable posture suitable for archery), automatically generates a set of "drawing the bow and aiming" and "arrow shooting" animation sequences that are adapted to the skeletal model of "virtual character F" and have a matching style, significantly reducing the workload of animators creating from scratch.

[0187] In this embodiment, the model correlation degree between the first virtual character and the second virtual character is obtained; based on the model correlation degree and the animation sequence of the first virtual character, the animation sequence corresponding to the second virtual character is generated. This method can utilize the high-quality motion data of existing characters and selectively adapt and generate by calculating the correlation degree. While ensuring the quality and uniqueness of the new character's actions, it can significantly improve the production efficiency of animation content, reduce the cost of creating exclusive animations for a large number of virtual characters in digital cultural products, support rapid iteration of projects and large-scale expansion of content, and realize the intelligent reuse and migration of animation resources and behavior patterns between virtual characters.

[0188] Indicatively, Figure 6 A flowchart of a program update method provided in one embodiment of this specification is shown, including: Step 602: Obtain the dialogue model of the virtual character and the target dialogue model, and deploy the target dialogue model to the first server. The target dialogue model is trained using the dialogue model training method described above. Step 604: Obtain the first running data of the target dialogue model in the first server, and obtain the second running data of the dialogue model in the second server; Step 606: Compare the first running data and the second running data, and determine whether to deploy the target dialogue model to the second server based on the comparison result.

[0189] The concepts of dialogue models for virtual characters and target dialogue models have been described above and will not be repeated here.

[0190] The first server is a server node used for model testing or canary releases. For example, a server cluster serving a small group of specific test users or group B in an A / B test divided according to traffic proportions.

[0191] Optionally, one way to deploy the target dialogue model to the first server is to directly copy the target dialogue model's files to a specified directory on the first server and start the corresponding service process. Another way to deploy the target dialogue model to the first server is to use a configuration management tool or service mesh to route traffic destined for the model service to the first server. This specification does not limit this approach.

[0192] The first set of operational data is a collection of data related to model performance, user interaction, and business results collected during the execution of the target dialogue model on the first server. Examples include the model's average response latency and error rate, the average number of dialogue turns between the user and "virtual character A," the five-star rating rate for dialogue quality, and the frequency of triggering sensitive word filtering.

[0193] The second server is a server node that runs the original dialogue model. For example, a server cluster serving most online users or group A in an A / B test.

[0194] The second set of running data is a collection of similar metrics collected during the running of the original dialogue model on the second server.

[0195] Optionally, one way to obtain the initial running data of the target dialogue model on the first server is by embedding tracking code in the model service to send log data to the monitoring and analysis platform in real time. Another approach is to periodically extract relevant metrics from server log files or performance monitoring tools. This specification does not limit the scope of this approach.

[0196] The method for obtaining the second running data of the dialogue model on the second server can be the same as the method for obtaining the first running data of the target dialogue model on the first server, and will not be elaborated here.

[0197] Optionally, one approach to comparing the first and second running data is to calculate the statistical significance of the differences between the two sets of data on key indicators (such as user satisfaction and dialogue depth). Another approach is to apply hypothesis testing methods (such as t-tests) to determine whether the target model is significantly better than the baseline model. This specification does not limit the scope of the embodiments described herein.

[0198] For example, the target dialogue model (the newly trained "virtual character A" v2.0 model) is deployed on the first server, serving 5% of random users. The original dialogue model (v1.0 model) is deployed on the second server, serving the remaining 95% of users. After one week of operation, the collected data shows that users using the v2.0 model had an average of 8.5 dialogue rounds (first run data), significantly higher than the 6.2 rounds using the v1.0 model (second run data), and user subjective ratings also significantly improved.

[0199] In this embodiment, the dialogue model of the virtual character and the target dialogue model are obtained, and the target dialogue model is deployed to a first server. First running data of the target dialogue model on the first server and second running data of the dialogue model on a second server are obtained. The first and second running data are compared, and a decision is made based on the comparison result to deploy the target dialogue model to the second server. This allows for objective evaluation of the new model's effectiveness using small-scale user interaction data, and a decision is made based on empirical results to replace the old model entirely. This ensures the stability and continuous optimization of online service quality, avoids the potential for widespread user experience degradation or operational incidents caused by directly releasing a defective model in its entirety, and reduces the risk of launching a new model.

[0200] In one optional embodiment of this specification, before deploying the target dialogue model to the first server, the method further includes: Construct a container image corresponding to the target dialogue model; Deploying the target dialogue model to the first server includes: Deploy the container image corresponding to the target dialogue model to the first server.

[0201] A container image is a standardized, portable software package that encapsulates the target dialogue model and its runtime dependencies.

[0202] Optionally, one way to build the container image corresponding to the target dialogue model is to write a Dockerfile, specifying the base image, copying the model files and inference code, setting the startup command, and executing the build command. Another way to build the container image corresponding to the target dialogue model is to use a dedicated model containerization tool provided by the cloud platform for automated packaging. This specification does not limit this approach in the embodiments.

[0203] For example, the trained "virtual character A" v2.0 model file, Python inference script, dependency library list, etc. are packaged into a Docker image named athena-dialog-v2:1.0 and pushed to a private image repository.

[0204] In the embodiments of this specification, by constructing a container image corresponding to the target dialogue model and deploying the container image corresponding to the target dialogue model to the first server, problems arising after the target dialogue model is deployed to the server can be detected in a timely manner, and the target dialogue model can be ensured to run in the same way on different servers. This simplifies the deployment complexity and facilitates integration with the container orchestration system to achieve automated deployment and version rollback.

[0205] In one optional embodiment of this specification, the comparison results include whether the target dialogue model meets the preset indicators or not. Determining whether to deploy the target dialogue model to the second server based on the comparison results includes: If the comparison results show that the target dialogue model meets the preset indicators, the target dialogue model will be deployed to the second server; if the comparison results show that the target dialogue model does not meet the preset indicators, the target dialogue model will be optimized.

[0206] The preset metrics are predefined quantitative thresholds or sets of conditions used to evaluate whether a new version of the model is superior to the old version. For example, it may require that the average user rating of the new model improves by at least 5% and the lower limit of the confidence interval is greater than zero, while the average response latency increases by no more than 50 milliseconds.

[0207] The target dialogue model achieves a preset metric, which is the first running data showing an improved state compared to the second running data on one or more preset key metrics.

[0208] The target dialogue model fails to meet the preset indicators, which is the first running data point indicating that the preset improvement standards are not met on any key indicator, and / or the performance is degraded.

[0209] Optionally, one way to optimize the target dialogue model is to augment the training data and initiate a new round of fine-tuning based on erroneous dialogue cases or low-scoring feedback collected from the first server. Another way to optimize the target dialogue model is to directly adjust the model's service parameters or prompt word templates. This specification does not limit this approach.

[0210] For example, the preset metric is "user satisfaction improvement > 3%". The comparison results show that the v2.0 model's satisfaction improved by 4.8%, reaching the preset metric. The system automatically triggers the process of fully deploying the v2.0 container image to all second servers (i.e., the production environment). If the results show a decrease in satisfaction or the improvement does not reach the threshold, the system issues an alarm and automatically rolls back the first server to the v1.0 image. Simultaneously, it sends the collected failure cases into the training pipeline to generate the v2.1 model.

[0211] In the embodiments described in this specification, if the comparison result shows that the target dialogue model meets the preset indicators, the target dialogue model is deployed to the second server; if the comparison result shows that the target dialogue model does not meet the preset indicators, the target dialogue model is optimized. This ensures that target dialogue models that meet the preset performance indicators are deployed normally, and target dialogue models that do not meet the indicators are further optimized, thus ensuring the stable and efficient operation of the target dialogue model after deployment to the server.

[0212] In one optional embodiment of this specification, the target dialogue model is applied to the target program, and the second server is multiple servers; Deploying the target dialogue model to a second server includes: Register the target dialogue model to the target program; Build a container image of the target program and distribute the target program to multiple servers in parallel through a pre-built program distribution system.

[0213] The target program is a digital cultural product application that includes virtual character dialogue functionality.

[0214] An application deployment system is a software system used to automatically and in batches deploy new versions of applications to production server clusters.

[0215] Optionally, one way to register the target dialogue model to the target program is to update the model service version number or image tag in the program's configuration center. Another way to register the target dialogue model to the target program is through a service discovery mechanism, directing the program's calls to the dialogue model to a new model service instance. This specification does not limit this approach.

[0216] Alternatively, one implementation of building the container image of the target program can be based on a program codebase containing the latest model configuration, automatically building the image using a continuous integration pipeline. Another implementation can be manually executing a build script. This specification does not limit the implementation to these methods.

[0217] Alternatively, the deployment system can be constructed using Kubernetes Deployment and Service resources for orchestration. Another approach is to build it using tools such as Ansible or Terraform. This specification does not limit the specific implementation of this method.

[0218] For example, the verified v2:1.0 image version number is updated in the configuration file of a game server. Subsequently, the CI / CD pipeline builds a new version of the game server image containing the new dialogue model based on this configuration. Finally, the new version of the game server is synchronously deployed to hundreds of production environment servers through the cluster's deployment system, completing a full update.

[0219] In the embodiments described in this specification, the target dialogue model is registered to the target program; a container image of the target program is constructed; and the target program is deployed to multiple servers in parallel through a pre-built program deployment system. This enables scalable and automated delivery from single model updates to overall application version releases, ensuring the coordinated release of model updates and other components in the application. It supports efficient and reliable full upgrades in large-scale distributed systems, guaranteeing a smooth transition and consistent user experience.

[0220] Indicatively, Figure 7 This specification shows a schematic diagram of the structure of a program product provided in one embodiment, including: Dialogue module 702, prop generation module 704 and numerical balance module 706; Dialogue module 702 is configured to receive the target question sent by the front end, and use the target dialogue model of the virtual character to reason about the target question and generate the target answer. The target dialogue model of the virtual character is trained by the dialogue model training method described above. The prop generation module 704 is configured to generate target props for the user to use based on the instructions input by the user. The numerical balancing module 706 is configured to acquire user operation data in the target program and adjust the items generated by the item generation module 704 based on the operation data.

[0221] Dialogue module 702 is a functional unit responsible for handling natural language dialogue interactions between users and virtual characters.

[0222] The item generation module 704 is a functional unit responsible for dynamically generating virtual items in the game based on user needs or system rules.

[0223] The numerical balance module 706 is a functional unit responsible for monitoring the game's economic system and player experience, and dynamically adjusting item attributes or generation rules to maintain the health of the system.

[0224] User input commands are natural language descriptions or structured requests expressing the user's needs for item creation. For example, "Craft me a silver bow suitable for the goddess of the hunt."

[0225] The target item is a specific virtual item instance generated according to user instructions. For example, a silver bow named "Moon Goddess's Kiss" with specific attack power, range, and special effects.

[0226] User activity data within the target application is a collection of records and results of user interactions with the item system within the application. Examples include the frequency with which users acquire, use, and trade items, and correlation data between the usage rate and win rate of different items.

[0227] Optionally, one way to generate a target prop for user use based on user input can be through a trained text-to-prop generation model, which directly parses the user's instructions into prop attribute parameters and instantiates them. Another way to generate a target prop for user use based on user input can be to first understand the user's intent through a dialogue module, and then call a preset prop template library for combination and parameterization. This specification does not limit the embodiments in this way.

[0228] Optionally, one way to obtain user operation data in the target program is by recording user behavior logs on the server side and aggregating and analyzing them. Another way to obtain user operation data in the target program is by collecting it from user behavior statistical events reported by the front end. This specification does not limit this approach.

[0229] For example, in a game, a user says to the virtual character "F" in the dialogue module, "I need a bow that can accurately hit prey under moonlight." After understanding the intent, the dialogue module sends a structured request, "Generate weapon: bow; traits: moonlight, accuracy," to the item generation module. The item generation module calls its internal model to generate a silver bow with attributes of "increased nighttime attack power" and "accuracy bonus." The numerical balance module continuously monitors the usage of such high-accuracy bows across the entire server. If it detects that this is causing an imbalance in PVP win rates, it automatically fine-tunes the generation probability or slightly reduces the bonus value to maintain the fairness of the overall game environment.

[0230] In the embodiments described in this specification, by integrating a dialogue module with character knowledge, an item generation module, and an adaptive numerical balance module, it is possible to understand and respond to the user's complex natural language needs, create personalized virtual items, and ensure the user's data balance in digital cultural products.

[0231] In one optional embodiment of this specification, the numerical balancing module is obtained by training at least one pre-built agent.

[0232] An intelligent agent is a decision-making model that can perceive the environment, make decisions, and execute actions to achieve a goal. In the state space constituted by the target program environment, the decision-making model learns to select the optimal action to influence the numerical balance based on a preset reward signal.

[0233] Therefore, the numerical balancing module is a decision engine (decision model) that solidifies, encapsulates and integrates the optimal balancing strategy learned by at least one agent during the training process. It has the ability to continuously learn and adapt and evolve, and can proactively and accurately respond to changes in the target program environment.

[0234] For example, the numerical balancing module consists of a reinforcement learning agent trained in a simulated game environment. This agent takes server-wide item distribution, player win rates, and economic indicators as state inputs, and adjusts specific item generation parameters or attributes as actions, using long-term indicators such as "player retention rate" and "pay-to-win balance" as reward signals. Through training, the agent learns to automatically execute subtle parameter adjustments, maintaining ecological balance with an invisible hand.

[0235] In the embodiments of this specification, a numerical balance module is obtained by training at least one pre-constructed intelligent agent, which can realize automated and intelligent balance management of complex game ecosystems. This overcomes the lag and limitations of balancing methods based on fixed rules or manual analysis, enabling the target program to perceive environmental changes in real time and make dynamic adjustments. It continuously optimizes the overall user experience in a data-driven manner, thereby improving the operability and life cycle of large-scale digital cultural products.

[0236] The above is an illustrative scheme of a program product according to this embodiment. It should be noted that the technical solution of this program product and the technical solution of the aforementioned dialogue model training method belong to the same concept. Details not described in detail in the technical solution of the program product can be found in the description of the technical solution of the aforementioned dialogue model training method. Furthermore, the components in the program product embodiment should be understood as functional modules necessary to implement each step of the program flow or each step of the method; these functional modules are not actual functional divisions or separations. The program product claims defined by such a set of functional modules should be understood as a functional module architecture that primarily implements the solution through the computer program described in the specification, and not as a physical program product that primarily implements the solution through hardware.

[0237] Figure 8 This specification illustrates a structural block diagram of a computing device according to one embodiment. The components of the computing device 800 include, but are not limited to, a memory 810 and a processor 820. The processor 820 is connected to the memory 810 via a bus 830, and a database 850 is used to store data.

[0238] The computing device 800 also includes an access device 840, which enables the computing device 800 to communicate via one or more networks 860. Examples of these networks include a Public Switched Telephone Network (PSTN), a Local Area Network (LAN), a Wide Area Network (WAN), a Personal Area Network (PAN), or a combination of communication networks such as the Internet. The access device 840 may include one or more of any type of wired or wireless network interface (e.g., a Network Interface Controller (NIC)), such as an IEEE 802.11 Wireless Local Area Network (WLAN) interface, a Worldwide Interoperability for Microwave Access (Wi-MAX) interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, or a Near Field Communication (NFC) interface.

[0239] In one embodiment of this specification, the above-described components of the computing device 800 and Figure 8 Other components, not shown, can also be connected to each other, for example, via a bus. It should be understood that... Figure 8 The block diagram of the computing device shown is for illustrative purposes only and is not intended to limit the scope of this specification. Those skilled in the art can add or replace other components as needed.

[0240] The computing device 800 can be any type of stationary or mobile computing device, including mobile computers or mobile computing devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable computing devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary computing devices such as desktop computers or personal computers (PCs). The computing device 800 can also be a mobile or stationary server.

[0241] The memory 810 is used to store computer programs / instructions, and the processor 820 is used to execute the following computer programs / instructions, which, when executed by the processor, implement the steps of the above-mentioned model training method.

[0242] The above is an illustrative scheme of a computing device according to this embodiment. It should be noted that the technical solution of this computing device and the technical solution of the dialogue model training method described above belong to the same concept. For details not described in detail in the technical solution of the computing device, please refer to the description of the technical solution of the dialogue model training method described above.

[0243] An embodiment of this specification also provides a computer-readable storage medium storing a computer program / instructions that, when executed by a processor, implement the steps of the above-described dialogue model training method.

[0244] The above is an illustrative scheme of a computer-readable storage medium according to this embodiment. It should be noted that the technical solution of this storage medium belongs to the same concept as the technical solution of the dialogue model training method described above. For details not described in detail in the technical solution of the storage medium, please refer to the description of the technical solution of the dialogue model training method described above.

[0245] An embodiment of this specification also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the above-described dialogue model training method.

[0246] The above is an illustrative scheme of a computer program product according to this embodiment. It should be noted that the technical solution of this computer program product and the technical solution of the above-described dialogue model training method belong to the same concept. For details not described in detail in the technical solution of the computer program product, please refer to the description of the technical solution of the above-described dialogue model training method.

[0247] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0248] The computer instructions include computer program code, which may be in the form of source code, object code, executable file, or some intermediate form. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium may be appropriately added or removed according to the requirements of patent practice. For example, in some regions, according to patent practice, computer-readable media may not include electrical carrier signals and telecommunication signals.

[0249] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments in this specification are not limited to the described order of actions, because according to the embodiments in this specification, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in this specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to the embodiments in this specification.

[0250] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0251] The preferred embodiments disclosed above are merely illustrative of this specification. The optional embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the embodiments described herein. These embodiments are selected and specifically described in this specification to better explain the principles and practical applications of the embodiments, thereby enabling those skilled in the art to better understand and utilize this specification. This specification is limited only by the claims and their full scope and equivalents.

Claims

1. A method for constructing a character background knowledge base, characterized in that, include: Obtain the character background data of the virtual character; Extract the entities and their relationships from the character background data; Using the entities as nodes and the relationships as edges, a background knowledge graph of the virtual character is constructed, wherein the background knowledge graph includes at least one layer of knowledge graph, and the entity types of the entities in each layer of knowledge graph are different; By assigning corresponding weight information to each layer of the knowledge graph, a background knowledge graph containing the weight information is obtained. Based on the background knowledge graph containing weighted information, a background knowledge base for the virtual character is constructed, wherein the background knowledge base is used to provide relevant background knowledge as the context for retrieval enhancement generation when training the dialogue model of the virtual character.

2. The method according to claim 1, characterized in that, After obtaining the character background data of the virtual character, the process also includes: Acquire user status data and quantify the status data to obtain at least one status category; After setting corresponding weight information for each layer of the knowledge graph to obtain a background knowledge graph containing the weight information, the process further includes: The state category is associated with the target edge in the background knowledge graph containing weight information to obtain a background knowledge graph with embedded state data and weight information, wherein the target edge is at least two edges that start from the same node and are respectively connected to different entities of the same type. The construction of a background knowledge base for the virtual character based on the background knowledge graph containing weighted information, wherein the background knowledge base is used to provide relevant background knowledge as context for retrieval enhancement generation in training the dialogue model of the virtual character, includes: Based on the embedded state data and the background knowledge graph containing weight information, a background knowledge base for the virtual character is constructed. The background knowledge base is used to provide relevant background knowledge as the context for retrieval enhancement generation when training the dialogue model of the virtual character.

3. A dialogue model training method, characterized in that, include: Obtain a sample dataset, wherein the sample dataset includes sample questions and labeled responses, and the sample questions contain at least one type of entity and its corresponding weight information; The sample question is input into the dialogue model of the virtual character, and relevant background knowledge of the virtual character is retrieved from the background knowledge base based on the at least one type of entity and its corresponding weight information, wherein the background knowledge base is constructed according to the method described in claim 1; Using the relevant background knowledge as context, generate a predicted response to the sample question; Calculate the loss value based on the predicted response and the labeled response; The model parameters of the dialogue model are adjusted based on the loss value to obtain the trained target dialogue model of the virtual character.

4. The method according to claim 3, characterized in that, The dialogue model includes an attention module, which includes a low-rank linear layer. The step of adjusting the model parameters of the dialogue model based on the loss value to obtain the trained target dialogue model of the virtual character includes: Based on the loss value, the parameters of the low-rank linear layer of the attention module in the dialogue model are adjusted to obtain the trained target dialogue model of the virtual character.

5. A character control method, characterized in that, include: The target problem received from the front end; The target problem is analyzed to obtain the entity types of the entities in the target problem and their corresponding weight information; The target question, the entity types of the entities in the target question, and their corresponding weight information are input into the target dialogue model of the virtual character, so that the target dialogue model of the virtual character can reason about the target question based on the entity types of the entities and their corresponding weight information, and generate a target response. The target dialogue model of the virtual character is trained by the method described in claim 3. The target response is output to the front end.

6. The method according to claim 5, characterized in that, Also includes: Receive control commands for the virtual character sent by the front end; The control commands are input into the target motion control model to obtain the animation sequence of the virtual character; The animation sequence is rendered to the front end.

7. The method according to claim 6, characterized in that, Before inputting the control commands into the target motion control model to obtain the animation sequence of the virtual character, the method further includes: Construct multiple animation sub-sequences for the virtual character; The priority, relevance, and transformation relationship between each animation subsequence are determined, and multiple behavior levels are determined based on the priority and relevance. The behavior levels include parent behavior levels and child behavior levels. The parent behavior level consists of at least one child behavior level, and the child behavior level consists of at least one animation subsequence. A behavior tree is constructed using the parent behavior hierarchy as the selection node and / or sequence node, the condition executed by the parent behavior hierarchy as the condition node, and the animation subsequence in the child behavior hierarchy as the execution node. A state machine is constructed using each animation subsequence in the same sub-behavior level as a state node and the transformation relationship between each animation subsequence as an edge. The behavior tree is associated with the state machine to obtain the initial action control model; The initial motion control model is trained to obtain the target motion control model.

8. The method according to claim 7, characterized in that, Before inputting the control commands into the target motion control model to obtain the animation sequence of the virtual character, the method further includes: Obtain the environmental data of the virtual character; The step of inputting the control commands into the target motion control model to obtain the animation sequence of the virtual character includes: The control commands and environmental data are input into the target action control model. Based on the control commands and environmental data, the model traverses each node of the behavior tree to generate behavior decision commands. The model then generates the animation sequence of the virtual character based on the behavior decision commands through the state machine.

9. The method according to claim 7, characterized in that, The virtual character includes a first virtual character and a second virtual character, and the animation sequence of the virtual character includes the animation sequence of the first virtual character; After inputting the control commands into the target motion control model to obtain the animation sequence of the virtual character, the method further includes: Obtain the model correlation degree between the first virtual character and the second virtual character; Based on the model correlation and the animation sequence of the first virtual character, an animation sequence corresponding to the second virtual character is generated.

10. A program update method, characterized in that, include: Obtain the dialogue model of the virtual character and the target dialogue model, and deploy the target dialogue model to the first server, wherein the target dialogue model is trained by the method described in claim 3; Obtain the first running data of the target dialogue model in the first server, and obtain the second running data of the dialogue model in the second server; The first running data and the second running data are compared, and a decision is made based on the comparison result as to whether to deploy the target dialogue model to the second server.

11. The method according to claim 10, characterized in that, Before deploying the target dialogue model to the first server, the method further includes: Construct the container image corresponding to the target dialogue model; Deploying the target dialogue model to the first server includes: Deploy the container image corresponding to the target dialogue model to the first server.

12. The method according to claim 11, characterized in that, The comparison results include whether the target dialogue model meets the preset indicators and whether the target dialogue model does not meet the preset indicators. The step of determining whether to deploy the target dialogue model to the second server based on the comparison results includes: If the comparison result indicates that the target dialogue model meets the preset indicators, the target dialogue model will be deployed to the second server. If the comparison result indicates that the target dialogue model does not meet the preset indicators, the target dialogue model is optimized.

13. The method according to claim 12, characterized in that, The target dialogue model is applied in the target program, and the second server consists of multiple servers; Deploying the target dialogue model to the second server includes: Register the target dialogue model to the target program; A container image of the target program is constructed, and the target program is deployed in parallel to the multiple servers through a pre-built program deployment system.

14. A program product, characterized in that, This includes a dialogue module, an item generation module, and a numerical balance module; The dialogue module is configured to receive a target question sent by the front end, reason about the target question using a target dialogue model of a virtual character, and generate a target response, wherein the target dialogue model of the virtual character is trained by the method described in claim 3. The prop generation module is configured to generate target props for the user to use based on the instructions input by the user. The numerical balancing module is configured to acquire the user's operation data in the target program and adjust the items generated by the item generation module according to the operation data.

15. A computing device, characterized in that, include: Memory and processor; The memory is used to store computer programs / instructions, and the processor is used to execute the computer programs / instructions, which, when executed by the processor, implement the steps of the method according to any one of claims 1 to 13.

16. A computer-readable storage medium, characterized in that, It stores a computer program / instructions that, when executed by a processor, implement the steps of the method according to any one of claims 1 to 13.

Images