A human-machine relationship interaction system and method based on a commitment state machine

Abstract

This invention provides a human-computer interaction system and method based on a commitment state machine, comprising: a behavior event acquisition module that converts input into standardized behavior events; a commitment identification and modeling module for judging and generating commitment objects; a commitment state management module for creating and maintaining the state of commitment objects; a verification and judgment module that, when fulfillment conditions are met, outputs an instruction to the commitment state management module to update the state of the commitment object to a fulfillment state; a consequence decision module that generates corresponding consequence event decisions based on the current state of the commitment object and pre-stored consequence mapping rules; and a behavior generation and output module that generates system response behavior based on the results of the consequence event decisions. This invention continuously verifies and manages commitment states, dynamically adjusts subsequent behaviors based on state changes, and realizes a human-computer relationship evolution mechanism with causal consequences.

Description

Technical Field

[0001] This invention relates to the fields of artificial intelligence and human-computer interaction technology, specifically to a human-computer relationship interaction system based on a commitment state machine and its implementation method, applicable to virtual role systems, intelligent companion systems, multi-role interaction systems, and artificial intelligence application scenarios with long-term interaction relationship management needs. Background Technology

[0002] Most existing human-computer interaction systems respond based on single-turn or short-term contexts. Their core logic is usually built around instant input and instant output, lacking the ability to manage cross-time interaction relationships in an engineered manner.

[0003] In long-term interaction scenarios, users and systems often form relational behaviors involving commitment, expectation, fulfillment, and breach of contract. However, existing technologies typically treat these contents only as abstract descriptions at the semantic or emotional level, lacking verifiable, traceable, and consequence-generating system-level mechanisms. This results in a lack of continuity and consistency in interaction behavior, making it difficult to simulate the dynamic evolution of real relationships.

[0004] Therefore, there is an urgent need for a human-computer interaction system that can realize commitment recognition, state management, verification and judgment, and consequence feedback at the engineering level. Summary of the Invention

[0005] The purpose of this invention is to provide a human-computer interaction system and method based on a commitment state machine. By performing structured modeling of commitments in interaction behavior and continuously verifying and managing the commitment state, subsequent behaviors can be dynamically adjusted according to state changes, thereby realizing a human-computer relationship evolution mechanism with causal consequences.

[0006] To achieve the above objectives, this invention provides a human-computer interaction system based on a commitment state machine, characterized by comprising a behavior event acquisition module, a commitment identification and modeling module, a commitment state management module, a verification and judgment module, a consequence decision module, and a behavior generation and output module. The behavior event acquisition module receives interactive input from the user and converts it into standardized behavior events. The commitment identification and modeling module determines whether a standardized behavior event constitutes a commitment and generates a commitment object when a commitment is constituted. The commitment state management module creates the state of the commitment object and maintains and updates the state of the commitment object. The verification and judgment module is configured to output an instruction to the commitment state management module that meets the fulfillment conditions when the fulfillment conditions are met, thereby updating the state of the commitment object to a fulfillment state. The consequence decision module generates corresponding consequence event decisions based on the current state of the commitment object and pre-stored consequence mapping rules. The behavior generation and output module generates specific system response behaviors based on the results of the consequence event decisions.

[0007] The states of the commitment objects include pending verification, fulfillment, default, and expired states. The commitment state management module maintains and updates the state of the commitment objects in response to the verification and judgment module's instructions on fulfilling the fulfillment conditions, the commitment type of the commitment object, and the validity period of the commitment object. The commitment state management module is configured as follows: when a commitment object is created, it is assigned an initial state, which is pending verification; fulfillment, default, and expired states are the final states. Once a commitment object enters the fulfillment or default state in a judgment cycle, its state will not be rolled back in subsequent judgment cycles; when multiple conditions for updating to the final state are triggered in the same judgment cycle, the final state is determined according to the following priority order: fulfillment state > default state > expired state.

[0008] The verification and judgment module is further configured to: extract a set of performance conditions and a set of default conditions from the attributes of the commitment object, wherein the set of performance conditions includes at least one performance condition and the set of default conditions includes at least one default condition; when a default condition is met, an instruction to meet the default condition is output to the commitment status management module to update the status of the commitment object to a default status; the commitment status management module first determines whether the performance conditions are met, and if so, updates the status of the commitment object to a performance status; if not, it determines whether the default conditions are met, and if so, updates the status of the commitment object to a default status; if none of the aforementioned conditions are met, it determines whether the commitment is valid. The system determines whether the expiration condition is met by checking if the effective time frame has expired. If it is, the status of the commitment object is updated to either expired or defaulted, depending on the commitment type. If an instruction from the verification and judgment module confirms that the performance conditions are met, then the performance conditions are met. If an instruction from the verification and judgment module confirms that the default conditions are met, then the default conditions are met. If the commitment object has not met the performance judgment conditions when the effective time frame of the commitment expires, then the expiration condition is met. When the expiration condition is met, if the commitment type of the commitment object is a rigid commitment, then the status is updated to defaulted. If the commitment type of the commitment object is a vague commitment, then the status is updated to expired.

[0009] Whether a standardized behavioral event constitutes a commitment is determined based on at least one of the following preset commitment criteria: rule matching criteria; or, the classification result output by the semantic classification model is a commitment; the rule matching criteria are keyword matching criteria, semantic template matching criteria, or sentence structure recognition criteria.

[0010] A two-stage processing mechanism is used to determine whether a standardized behavioral event constitutes a commitment, which specifically includes:

[0011] A1: When the input natural language interactive content meets any of the rule matching conditions, it is identified as a candidate commitment statement; the rule matching conditions include: hitting the preset commitment keyword set, conforming to the predefined semantic template structure, and satisfying specific commitment sentence structure features;

[0012] A2: Further evaluate the candidate commitment statement by combining the context, confidence threshold and verifiability rules to determine whether the standardized behavioral event constitutes a commitment. If so, generate a commitment object.

[0013] When determining whether a standardized behavioral event constitutes a commitment based on the classification result output by the semantic classification model, the semantic classification model includes traditional classification models based on feature vectors; neural network models based on deep learning; and semantic determination models based on large-scale language models.

[0014] The output of the semantic classification model includes at least one of the following: binary classification results of commitment and non-commitment, commitment confidence, commitment type, and commitment element extraction results.

[0015] When a commitment is formed, a commitment object is generated, specifically including: modeling the standardized behavioral events constituting the commitment as a structured commitment object; wherein, the commitment object includes two types of attributes: core attributes and optional extended attributes; the core attributes include: a unique commitment identifier; the commitment subject; the commitment content; the commitment creation time; and the current commitment status; the optional extended attributes include: the commitment validity period, the set of performance conditions, the commitment type, priority, commitment confidence, and verification mode identifier; when the commitment identification and modeling module can extract or derive the optional extended attributes from the interaction content, it uses the obtained optional extended attributes to fill in the values; otherwise, it uses default rules or fallback rules to complete the default values ​​of the optional extended attributes; the commitment types are divided into: result-oriented commitments, behavior frequency commitments, relationship attitude commitments, and fuzzy commitments according to semantic features; result-oriented commitments, behavior frequency commitments, and relationship attitude commitments are all rigid commitments.

[0016] The commitment object includes a verification mode identifier as an optional extended attribute; the verification mode identifier is generated based on the commitment type and / or the set of performance conditions; the verification mode identifier includes full condition satisfaction type, key condition satisfaction type, and weighted scoring type; when the verification and judgment module performs verification, if the verification mode identifier is full condition satisfaction type, then all performance conditions are met within the commitment validity period, and the performance conditions are considered met; if the verification mode identifier is key condition satisfaction type, then key conditions are pre-marked among multiple performance conditions, and the performance conditions are considered met as long as the key conditions are met; if the verification mode identifier is weighted scoring type, then different weight parameters are assigned to each performance condition, and the performance conditions are considered met by accumulating the score to see if a preset threshold is reached.

[0017] The consequence event decision-making includes: increasing or decreasing relationship value and trust value; adjusting emotional state; response delay strategy; rejection or cold treatment strategy; and generating response strategy identifier. The probability of rejection or cold treatment strategy corresponds to the relationship value. The response delay strategy is used to superimpose with other delays to obtain the total delay. When the commitment status is in default, a mandatory consequence event is generated first as the consequence event decision. When the commitment status is in expired status, a lightweight consequence event is generated, or no mandatory consequence event is generated, as the consequence event decision. When the commitment status is in fulfillment status, a positive feedback consequence event is generated as the consequence event decision. The behavior generation and output module generates specific system response behaviors, specifically including: first, determining whether a response strategy identifier exists; if it exists, generating a text reply based on the response strategy identifier using the text generation module; if it does not exist, further determining whether a rejection or cold treatment strategy exists; if it exists, executing a rejection or cold treatment response; if it does not exist, generating a text reply based on the emotional state; subsequently, performing a delayed response based on the total delay.

[0018] The aforementioned human-computer interaction system based on commitment state machine further includes a relationship state storage module and a module scheduling and data bus module. The relationship state storage module is used to store commitment objects and their states, historical results of whether the performance conditions are met, relationship values ​​and their change records. The module scheduling and data bus module is used to coordinate the data flow and calling order of the behavior event acquisition module, commitment identification and modeling module, commitment state management module, verification and judgment module, consequence decision module, behavior generation and output module, and relationship state storage module.

[0019] On the other hand, the present invention provides a human-computer relationship dynamics interaction method based on a commitment state machine, comprising the following steps:

[0020] S1: Utilize the behavior event acquisition module to receive interactive input from users and convert it into standardized behavior events;

[0021] S2: Use the commitment identification and modeling module to determine whether a standardized behavioral event constitutes a commitment, and generate a commitment object when a commitment is constituted;

[0022] S3: Use the commitment status management module to create the status of the commitment object. At this time, the status of the commitment object is pending verification.

[0023] S4: Using the verification and judgment module, when the performance conditions are met, output the instruction that the performance conditions are met to the commitment status management module, so that the commitment status management module updates the status of the commitment object to the performance status.

[0024] S5: Using the consequence decision module, generate corresponding consequence event decisions based on the current state of the commitment object and the pre-stored consequence mapping rules;

[0025] S6: Utilize the behavior generation and output module, which is used to generate specific system response behaviors based on the results of consequence event decisions.

[0026] The system of this invention performs structured modeling of commitments in interactive behavior, creates, continuously verifies and manages the validity period of commitments, and can dynamically adjust subsequent behaviors according to state changes. It realizes the engineering management of commitment fulfillment and breach, enables human-computer interaction to have cross-time consistency, realizes a human-computer relationship evolution mechanism with causal consequences, elevates the human-computer relationship evolution from the semantic layer to the system decision layer, and supports the parallel management of multiple commitments and multiple roles. Attached Figure Description

[0027] Figure 1 This is a system framework diagram of the human-computer interaction system based on commitment state machine according to the present invention;

[0028] Figure 2 This is a diagram illustrating the principle of state transition in a commitment.

[0029] Figure 3 This is a flowchart of the human-computer dynamic interaction method based on commitment state machine according to the present invention. Detailed Implementation

[0030] The present invention will be further described below with reference to specific embodiments. It should be understood that the following embodiments are for illustrative purposes only and are not intended to limit the scope of the invention.

[0031] As shown in Figure 1, the human-computer interaction system based on a commitment state machine of the present invention includes: a behavior event acquisition module 101, a commitment identification and modeling module 102, a commitment state management module 103, a verification and judgment module 104, a consequence decision module 105, a behavior generation and output module 106, a relationship state storage module 107, and a module scheduling and data bus module 108 connected to all the above modules in sequence. The modules are connected through event streams and data structures to form a closed-loop relationship system.

[0032] The behavior event acquisition module 101 receives interactive input from the user and converts it into standardized behavior events that the system can process. These standardized behavior events are then sent to the commitment recognition and modeling module 102.

[0033] In this embodiment, the input sources for the behavioral events include, but are not limited to: text input; speech-to-text input; and interactive operation events.

[0034] Each behavioral event must include at least the following fields: user identification information; behavioral content; timestamp of the behavioral occurrence; and behavioral context identifier.

[0035] The commitment identification and modeling module 102 is used to determine whether a standardized behavioral event constitutes a commitment, and generates a commitment object when a commitment is constituted. The generated commitment object is sent to the relational state storage module 107 for storage.

[0036] Determining whether a standardized behavioral event constitutes a commitment (i.e., identifying a commitment) is based on at least one of the following preset commitment criteria: rule matching criteria, such as keyword matching criteria, semantic template matching criteria, or sentence structure recognition criteria; or, the classification result output by the semantic classification model is a commitment. When a standardized behavioral event meets the preset commitment criteria, it is determined that the standardized behavioral event constitutes a commitment. In other words, the system can use either rule-based recognition or a combination of rules and semantic classification models for commitment identification.

[0037] 1) In this embodiment, when determining whether a standardized behavioral event constitutes a commitment based on rule matching conditions, the present invention employs a two-stage processing mechanism to determine whether a standardized behavioral event constitutes a commitment, which specifically includes:

[0038] Step A1: Candidate Commitment Recall Phase: When the input natural language interaction content meets any rule matching condition, it is identified as a candidate commitment statement.

[0039] The rule matching conditions include: hitting the preset set of commitment keywords (i.e., keyword matching conditions); conforming to the predefined semantic template structure (i.e., semantic template matching conditions); and satisfying specific commitment sentence structure features (i.e., sentence structure recognition conditions).

[0040] Among them, the three rule matching conditions—keyword matching condition, semantic template matching condition, and sentence structure recognition condition—do not have to be met simultaneously. Instead, step A2 can be executed as long as any one of the rule matching conditions is met.

[0041] Step A2: Commitment Confirmation and Judgment Stage: The candidate commitment statements are further judged by combining the context, confidence threshold and verifiability rules to determine whether the standardized behavioral event constitutes a commitment. If so, a commitment object is generated.

[0042] Keywords include commitment trigger words and revocable / uncertain words (used to reduce confidence). For example, commitment trigger words: "I promise / I definitely / I will / I agree / I promise / I will change / I won't / Next time I will definitely / Give it to you tomorrow / Spend the night with you." Vague / uncertain words (used to reduce confidence): "Maybe / Try / If I have time / Depend on the situation / Maybe / Strive."

[0043] Semantic template example:

[0044] [Subject] + [Committed Action] + [Time / Condition]: "I (Subject) will (Committed Action) chat with you every day (Time)"

[0045] [Commitment Action] + [Result / Deliverable]: "I will send you (the deliverable)."

[0046] [Negative Commitment]: "I will not (do) again."

[0047] Sentence structure example:

[0048] Future tense + first person: I + will / will / certainly + verb

[0049] Binding commitment: I guarantee + …

[0050] Conditional commitment: If... then I...

[0051] 2) In this embodiment, when determining whether a standardized behavioral event constitutes a commitment based on the classification result output by the semantic classification model, the semantic classification model can adopt various implementation forms, including but not limited to: traditional classification models based on feature vectors (SVM / Logistic Regression); neural network models based on deep learning (CNN / RNN / Transformer encoder); and semantic decision models based on large-scale language models (LLM). Specific semantic classification models and training methods are existing technologies.

[0052] In some embodiments, the output of the semantic classification model may be a binary classification result of commitment and non-commitment; in other embodiments, the output of the semantic classification model includes one or a combination of the following information: commitment confidence; commitment type; and optional commitment element extraction results (such as time, object, behavior, etc.).

[0053] The training data for semantic classification models can come from manually annotated historical dialogue samples, rule-generated synthetic samples, or re-annotated data from legally obtained public corpora.

[0054] When a commitment is formed, a commitment object is generated. Specifically, this involves modeling the standardized behavioral events constituting the commitment as a structured commitment object. The commitment object includes two types of attributes: core attributes and optional extended attributes. Core attributes are mandatory and include: a unique commitment identifier (used to distinguish different commitments); the commitment subject (distinguishing user or system role); the commitment content; the commitment creation time; and the current commitment status. Optional extended attributes include: the commitment's effective time range, the set of fulfillment conditions, the commitment type, priority, commitment confidence level, and verification mode identifier. If the commitment identification and modeling module 102 can extract or derive optional extended attributes from the interaction content, it uses the obtained optional extended attributes to fill in the values; otherwise, it uses default rules or fallback rules to complete the optional extended attributes with default values.

[0055] The valid time range for the commitment has a default value of 24h for short-term commitments (e.g., "I'll give it to you tomorrow") and 6h~48h for ambiguous commitments related to companionship. It is configurable.

[0056] The default value for the fulfillment condition set `verification_conditions` is: minimum fulfillable conditions, such as "whether there has been one instance of companionship / one instance of proactive response / one agreed-upon action (e.g., proactive chatting ≥ 1 time / response delay ≤ threshold) within the validity period"; at the same time, the commitment type is marked as an ambiguous commitment, and the commitment confidence is reduced. This design ensures that the commitment object can still enter the state machine for subsequent processing in scenarios with incomplete information.

[0057] Commitment types are categorized based on semantic features as follows: 1) Outcome-oriented commitments (e.g., "Complete goal X"); 2) Frequency-based commitments (e.g., "Perform the action at least N times"); 3) Relationship-based commitments (e.g., "Maintain concern" or "No longer give the cold shoulder"); 4) Vague / soft commitments (e.g., those containing vague terms like "try to," "soon," or "find time"). Outcome-oriented, frequency-based, and relationship-based commitments are all rigid commitments. Further refinement reveals that outcome-oriented commitments include commitments to deliver information / documents / results, and to provide resources / offers / unlock permissions; frequency-based commitments include commitments to accompany / chat, and commitments to schedule / meet / follow-up visits; relationship-based commitments include commitments to correct behavior / not do something again, commitments to apologize and repair, and commitments to privacy boundaries (e.g., "Don't ask this again"); while vague / soft commitments include commitments containing vague terms. If a commitment is of another type, such as a commitment to accompany / chat, but contains vague terms, it is classified as a vague / soft commitment.

[0058] Therefore, in this invention, vague commitments are still considered a form of commitment, but the commitment type is set to vague / soft commitment. For vague / soft commitments: a lower commitment confidence level is assigned; a shorter default validity period is adopted: for example, short-term commitments default to 24 hours; the default value of the performance condition set is the minimum fulfillable condition; in case of non-performance, only lightweight consequences are triggered, without triggering strong constraint consequences: such as trust -2, or only triggering an "explanation / compensation rhetoric" once, without triggering a cold treatment strategy. The above-mentioned mechanism of supplementing optional extended attributes with default values ​​enables the system to handle vague commitments that are common in real-world interactions without causing excessive penalties or logical conflicts.

[0059] In one embodiment, the verification pattern identifier is generated based on the commitment type; preferably, the verification pattern identifier is generated according to the constraint strength level corresponding to the commitment type, thereby realizing the determination of the verification pattern identifier based on the commitment semantics. Each commitment type corresponds to a commitment constraint strength level and a verification pattern identifier; for example, result-oriented commitments are at a strong constraint level (must be fulfilled, otherwise there will be consequences), and the verification pattern identifier is usually a full condition satisfaction type or a key condition satisfaction type. Behavior frequency commitments are at a medium constraint level (full fulfillment is recommended, failure has a slight impact), and the verification pattern identifier is usually a key condition satisfaction type or a weighted scoring type. Vague / soft commitments or relational attitude commitments are at a weak constraint level (only used as a tendency record), and the verification pattern identifier is usually a weighted scoring type.

[0060] In another embodiment, the verification pattern identifier is generated based on the set of performance conditions. The verification pattern identifier generates a verification pattern corresponding to the commitment object by analyzing the number, quantifiability, and logical relationships of the conditions in the set of performance conditions. This achieves dynamic strategy-based determination of the verification pattern identifier. The commitment identification and modeling module 102 analyzes whether the set of performance conditions bound to the commitment has the following characteristics: whether the number of conditions is greater than 1; whether there are "irreplaceable conditions" (such as explicit results); whether the conditions are naturally quantifiable; and whether there are logical dependencies between the conditions. For example, if all conditions are hard conditions that "must be true simultaneously" → full condition satisfaction type; if there are 1-2 irreplaceable core conditions among the conditions → key condition satisfaction type; if the conditions are multiple replaceable and superimposed behavioral signals → weighted scoring type.

[0061] In summary, the verification mode identifier is generated based on the commitment type and / or the set of performance conditions.

[0062] Therefore, in this embodiment, the applicable verification mode identifier is determined for the commitment object during the generation stage. The verification mode identifier is automatically determined by the commitment identification and modeling module 102 (or verification and judgment module 104) of the system based on factors such as commitment type and performance condition set, and is used as an attribute of the commitment object and stored in the relation state storage module 107.

[0063] The commitment status management module 103 is used to create the status of the commitment object and maintain and update the status of the commitment object in response to the instructions of the verification and judgment module 104 to meet the performance conditions, the commitment type of the commitment object, and the validity period of the commitment object.

[0064] The commitment state management module 103 (i.e., the commitment state machine) is set to: when a commitment object is created, an initial state is assigned to it, at which time the commitment object is in the state of pending verification;

[0065] This embodiment further defines the control logic of the commitment state machine.

[0066] The commitment status management module 103 is set to take the performance status, default status and expiration status as the final state.

[0067] The final state rule is as follows: once a commitment object enters a fulfillment state or a default state within a judgment period, its state will not be rolled back in subsequent judgment periods; the expired state is considered a final state by default (it will not roll back by default; whether reactivation is allowed can be implemented as an extension). Therefore, when a commitment meets the fulfillment conditions within the valid time frame, the commitment state is updated to "fulfillment state"; if it has been fulfilled before the end of the valid time frame, it will not change to "expired state" due to the expiration of the time frame.

[0068] When multiple conditions for updating to the final state are triggered within the same judgment period, the final state is determined according to the following priority order: performance state > default state > expiration state. This implements a priority rule for state updates. Through this rule, the unique determinacy of the commitment state under multiple conflicting conditions is ensured, and differentiated state feedback is achieved for different types of commitments.

[0069] In other words, the specific conflict resolution order is as follows: First, determine whether the performance conditions are met. If they are met (i.e., receive the instruction from the verification and judgment module 104 that the performance conditions are met), update the status of the commitment object to the performance status. If not, determine whether the breach conditions are met. If they are met, update the status of the commitment object to the breach status. If none of the above conditions are met, determine whether the effective time range of the commitment has expired to determine whether the expiration condition is met. If it is met, update the status of the commitment object to the expiration status or the breach status according to the commitment type.

[0070] Performance condition triggering path: If the verification and judgment module 104 receives an instruction that the performance conditions are met, then the performance conditions are met.

[0071] Non-expiration default triggering path: If the verification and judgment module 104 receives an instruction that the default conditions are met, then the default conditions are met.

[0072] Expiration condition triggering path: When the validity period of the commitment object expires, if the commitment object has not yet met the performance judgment condition (i.e., it has not received the instruction from the verification and judgment module 104 to meet the performance condition), then the expiration condition is met.

[0073] When the expiration condition is met, differentiated processing is performed according to the commitment type of the commitment object: if the commitment type of the commitment object is a rigid commitment, the status is updated to a default status; if the commitment type of the commitment object is a vague commitment (vague / soft commitments do not have clear performance failure conditions), the status is updated to an expired status.

[0074] Therefore, this invention differentiates between expired and default states, enabling differentiated processing of commitments with varying degrees of constraint strength. This avoids uniformly classifying all unfulfilled actions as defaults, thereby reducing erroneous penalties and improving the accuracy of relationship modeling. It should be noted that the logic for determining the commitment state does not require the default state to be predicated on expiration. The human-computer interaction system based on the commitment state machine allows for direct determination of the default state based on "explicit default behavior" within the commitment's valid timeframe. Within the commitment's valid timeframe, when the system detects a behavioral event conflicting with the commitment content, or a clear reverse behavior (such as refusal to execute, execution of the opposite behavior, or violation of constraints), it can determine that the default condition is met and directly update the commitment object to a default state (i.e., triggering a default before expiration).

[0075] The update of the commitment status is triggered by at least one of the following events to initiate a new judgment cycle: the fulfillment of performance conditions event;

[0076] 1) Events where the valid time frame has expired;

[0077] 2) External behaviors or interaction events;

[0078] 3) A conflict event in which multiple conditions for updating to the final state are met simultaneously.

[0079] Therefore, based on the aforementioned triggering events, the system performs status determination and updates on the committed object.

[0080] The commitment state management module 103 is also configured to periodically store the state of commitment objects in the form of structured data in the relational state storage module 107. The state of commitment objects in the relational state storage module 107 is used by users to index them by user, commitment subject, and creation time.

[0081] It should be noted that during the commitment status update process, the status update priority is: fulfillment status > default status > expired status; when multiple status trigger conditions are met, the status update with higher priority overrides the status update with lower priority. Furthermore, once the status of the commitment object is updated to fulfillment status, it will not be rolled back.

[0082] Therefore, by clearly distinguishing between expired and default states at the system level, this invention avoids the coarse-grained approach of "treating all unfinished tasks as failures" in traditional systems, and achieves: differentiated processing of different types of commitments; more realistic modeling of user behavior; engineered expression of "non-performance ≠ default" in relational systems; and reduced noise in relational systems caused by erroneous penalties.

[0083] In other words, in this embodiment, such as Figure 2 As shown, the commitment status includes at least the following status types: Pending; Fulfilled; Violated; and Expired. In other embodiments, the commitment status may also include a partially fulfilled status.

[0084] Furthermore, if there are mutually exclusive commitment objects (which are destined to conflict with each other), the commitment state management module 103 establishes a mutual exclusion group based on these commitment objects. In the mutual exclusion group, only the highest priority commitment or the latest commitment is taken from the commitment objects, and the remaining commitments are overwritten (e.g., marked as non-default status), thereby avoiding logical self-contradiction that could lead to incorrect penalties.

[0085] The verification and judgment module 104 is configured to: extract a set of performance conditions from the attributes of the commitment object, the set of performance conditions including at least one performance condition; when the performance condition is met, output an instruction to the commitment status management module 103 to update the status of the commitment object to the performance status;

[0086] In addition, the verification and judgment module 104 can also be configured to: extract a set of default conditions from the attributes of the commitment object, the set of default conditions including at least one default condition; when the default condition is met, output an instruction to the commitment status management module 103 to update the status of the commitment object to a default status; when neither the performance condition nor the default condition is met, keep the current status of the commitment object unchanged, or wait for subsequent triggering conditions.

[0087] Breach of contract conditions can be behavioral events that conflict with the content of the promise, or explicit reverse behaviors (such as refusal to perform, performance of the opposite behavior, violation of the constraint, etc.).

[0088] It should be noted that the intersection of the set of performance conditions and the set of default conditions is an empty set, and the two are completely mutually exclusive. In addition to the set of performance conditions and the set of default conditions, there are many conditions that correspond to situations where performance and default have not yet been determined.

[0089] Therefore, when the effective period of the commitment of the commitment object expires, the commitment status management module 103, which has not received an instruction to meet the performance conditions, will update the status of the commitment object to a default status (non-vague / soft commitment) or an expired status (vague / soft commitment).

[0090] The attributes of the commitment object are read from the relational state storage module 107.

[0091] Each commitment object corresponds to at least one set of performance conditions, and each performance condition in the set of performance conditions includes at least one of the following: a behavior triggering condition; a time condition; and a state condition. The behavior triggering condition, time condition, and state condition can be used individually or in combination to form a complete set of verification rules.

[0092] Behavioral trigger conditions: used to determine whether an observable behavioral event related to the promised content has occurred (e.g., chatting / giving gifts / completing tasks, etc.); Time conditions: used to limit whether the behavior occurs within the valid time frame of the promise, the deadline for completing the behavior, or the duration of the behavior (e.g., promising "chat 3 times within 7 days," checking whether the behavior is within the 7-day window; promising "chat for 1 hour," checking whether the chat duration meets the standard); State conditions: used to limit whether the relationship state between the human-computer interaction system and the promising subject meets the requirements when verification is performed (e.g., whether the trust value of the human-computer relationship is within the preset range, whether the AI's emotional state is interactive).

[0093] The verification operation of the verification and judgment module 104 is triggered under any of the following circumstances: receiving a new behavioral event; the end of the valid time range of the commitment; and periodic scheduling checks of the human-machine interaction system (the period duration can be set between seconds and hours depending on the commitment type and system load).

[0094] The verification and judgment module 104 executes the corresponding judgment logic to determine whether the performance conditions are met based on the verification mode identifier.

[0095] In this embodiment, the verification mode identifiers include full condition satisfaction type, key condition satisfaction type, and weighted scoring type; correspondingly, in the verification and judgment module 104, the judgment logic for whether the conditions are met includes:

[0096] If the verification mode is identified as "full condition satisfaction", then all performance conditions are met within the validity period of the commitment, which is considered as fulfilling the performance conditions. In this case, an instruction needs to be output to the commitment status management module 103 to update the status of the commitment object to the performance status. If the verification mode is identified as "key condition satisfaction", then key conditions are pre-marked among multiple performance conditions. As long as the key conditions are met, the performance conditions are considered as fulfilling the performance conditions. In this case, an instruction needs to be output to the commitment status management module 103 to update the status of the commitment object to the performance status. If the verification mode is identified as "weighted scoring", then different weight parameters are assigned to each performance condition. The performance conditions are considered as fulfilled if the cumulative score reaches a preset threshold.

[0097] In other embodiments, each verification mode identifier can be further subdivided into time-driven verification, behavior-triggered verification, event-matching verification, etc., and the corresponding judgment logic for whether the performance conditions are met is executed according to the subdivided verification mode.

[0098] The consequence decision module 105 is used to generate corresponding consequence event decisions based on the current state of the commitment object and the pre-stored consequence mapping rules. The current state of the commitment object is retrieved from the relational state storage module 107.

[0099] Specifically, the consequence decision module 105 generates consequence event decisions only for commitments currently in a performance or default state. For commitments in an expired state, it generates lightweight consequence event decisions or does not generate any consequence event decisions. For commitments currently in a pending verification state, it does not generate consequence event decisions. In the corresponding consequence decision generation module 105, the corresponding commitments can be deleted or marked as decided to avoid duplicate generation of consequence event decisions.

[0100] Consequence event decisions include, but are not limited to: increases or decreases in relationship and trust values; adjustments to emotional states; response delay strategies; rejection or cold-handing strategies; and the generation of response strategy identifiers; wherein the probability of rejection or cold-handing strategies corresponds to the relationship value. Therefore, when the commitment status is updated to a default status, the consequence decision module generates significant consequence event decisions, including immediate response adjustments or significant changes in relationship parameters. It should be noted that consequence event decisions are based on structured parameters, and the specific generated content is not intended to limit the scope of this invention.

[0101] Among these factors, low relationship values ​​and low trust values ​​affect the behavior strategy parameters of the behavior generation module. For example...

[0102] Response delay: Low trust value → Increased base delay (e.g., +2~10 seconds); For example, after the trust value drops, the output changes from "enthusiastic and immediate response" to "respond later + explanation". The explanation text can be: "I just saw it... I need to think about how to say it", "You haven't done what you promised last time, and I'm a little hesitant now", etc.

[0103] Probability of the cold treatment strategy: Low relationship value → Increased probability of triggering cold treatment (e.g., from 0% to 20%).

[0104] Probability of rejection strategy: Low relationship value → more conservative towards high-risk requests (more likely to reject / change the subject).

[0105] Emotional states include calm, hurt, etc., and are determined based on a range of emotional values. When calm transitions to hurt, a shorter, more restrained text response is generated, triggering a repair prompt. Examples of repair prompts include: "I'm feeling a bit down. Would you be willing to clarify what happened last time?" or "You said you would, but I didn't get to."

[0106] The response delay strategy is used to add to other delays to obtain the total delay. In this invention, the total delay = base delay (built-in system delay) + delay caused by trust value / relationship value + delay introduced by the response delay strategy. Furthermore, the total delay has an upper limit, such as 30 seconds, to avoid infinite delay.

[0107] The "cold treatment" strategy refers to not responding to a conversation.

[0108] The response strategy identifier is used to control the subsequent behavior generation module (such as the text generation module) to generate matching copy. The content of the copy is not specifically limited in this invention, but may be a script template / interaction strategy.

[0109] For example, a single breach of promise → response strategy identifier script_id = "breach_soft_warning_v1". The output of the behavior generation module is, for example: "You said you would last time... but I didn't get to hear it. Would you like to confirm it again now?".

[0110] Multiple breaches → Response strategy identifier script_id = "breach_cold_treatment_v2". The behavior generation module outputs, for example: "I don't really want to continue this topic right now. Let's talk about it when you're ready."

[0111] It should be noted that the innovation of this invention lies in the triggering conditions and closed-loop mechanism of the commitment, rather than in the specific wording. The above examples are merely illustrative of response formats and do not constitute a limitation of this invention.

[0112] In this embodiment, when a commitment is in an expired state, the consequence decision module generates lightweight consequence event decisions for the expired commitment object based on the commitment type and priority. These lightweight consequence event decisions include: fine-tuning of relationship parameters; slow decay of emotional state; and decay of trust level. These relationship parameters are only recorded in the relationship history ledger and do not trigger immediate response behavior.

[0113] If multiple commitments are breached simultaneously, the consequence event decisions for the same dimension of the multiple commitments will be based on the maximum value or weighted sum, with an upper limit (e.g., a single deduction of trust value cannot exceed 50). Furthermore, each consequence event decision will generate at most one rejection or cold-handing strategy, or response strategy identifier, in a single processing session. All other consequence event decisions for breaches will be downgraded to a minor warning (i.e., only a small deduction is made, without triggering additional response strategy identifiers or cold-handing strategies).

[0114] Consequence mapping rules can be stored in relation state storage module 107 (for easy versioning / traceability / updateability), and consequence decision module 105 is responsible for loading and executing consequence mapping rules.

[0115] Consequence mapping rules exist in the form of rule tables or rule engines, and at least include: commitment type; commitment state; and corresponding set of consequences. Examples of consequence mapping rules are shown in Table 1.

[0116] As mentioned above, commitment types include result-oriented commitments (such as "achieve goal X"), frequency-based commitments (such as "perform the action at least N times"), relationship-attitude commitments (such as "stay caring" or "no longer giving the cold shoulder"), and vague / soft commitments (such as those with vague words like "try," "soon," or "find time"). Further categorization includes result-oriented commitments such as information / document / result delivery commitments, resource provision / discounts / access unlocking commitments; frequency-based commitments such as commitments to companionship / chatting, and commitments to scheduling / meeting / follow-up visits; relationship-attitude commitments such as commitments to correct behavior / not do something again, commitments to apologize and repair, and commitments to privacy boundaries (such as "don't ask this again"); and vague / soft commitments include commitments with vague words. If a commitment is of another type, such as a commitment to companionship / chatting, but contains vague words, it is classified as a vague / soft commitment.

[0117] Table 1: Examples of Consequence Mapping Rules

[0118]

[0119] In this embodiment, the pre-stored consequence mapping rules are generated based on a consequence level grading mechanism; the consequence level grading mechanism includes: generating consequence event decisions of different levels according to the final state of the commitment object and the commitment type.

[0120] For example, when the commitment status is updated to the fulfillment status, a positive feedback consequence event is generated as a consequence event decision, such as increasing the relationship value, trust value, or unlocking special interactive content.

[0121] When a commitment status is updated to a default status, mandatory consequence events are generated first as the basis for consequence event decisions, such as significantly reducing the relationship value, triggering a cold treatment or rejection strategy, or significantly increasing response latency. Therefore, defaults on rigid commitments typically result in more severe consequences.

[0122] When a commitment is updated to an expired state, the system generates a lightweight consequence event or does not generate a mandatory consequence event as a consequence event decision. For example, it may only make minor adjustments to the relationship value, slowly decay the trust level, or generate only a reminder message without triggering strong intervention strategies such as cold treatment. This is mainly for vague or soft commitments.

[0123] Through the aforementioned consequence-level grading mechanism, the system achieves differentiated feedback on users' fulfillment behavior, making the evolution of human-machine relationships more nuanced and more in line with real social logic.

[0124] The behavior generation and output module 106 is used to generate specific system response behaviors based on the results of the consequence event decision (including relation values, emotional states, response strategy identifiers, total delay, and rejection or cold treatment strategies). The system response behaviors are then output to the user interface.

[0125] The generated system response behaviors include, but are not limited to: generating a text reply based on emotional state and response strategy identifier; performing a delayed response based on total latency; and executing a rejection or cold-handing response based on a rejection or cold-handing strategy. In this embodiment, it is first determined whether a response strategy identifier exists. If it exists, a text reply is generated using the text generation module based on the response strategy identifier. If it does not exist, it is further determined whether a rejection or cold-handing strategy exists. If it exists, a rejection or cold-handing response is executed. If it does not exist, a text reply is generated based on emotional state. Subsequently, a delayed response is performed based on total latency.

[0126] The relational state storage module 107 stores: commitment objects and their states; historical results of whether fulfillment conditions are met; relational values ​​and their change records. The commitment state management module 103 is responsible for the lifecycle and state changes of commitment objects; the relational state storage module 107 is responsible for the persistent storage and indexing of commitment objects and their states. When updating the state of a commitment object, the commitment state management module 103 needs to read the commitment object from the relational state storage module 107 and inject the updated commitment object back into the relational state storage module 107.

[0127] During verification, the verification and judgment module 104 reads core attributes such as the "valid time range of the commitment" and the "set of performance conditions" from the commitment object from the relational state storage module 107. The historical results of whether the performance conditions are met (time, result, evidence event) are sent by the verification and judgment module 104 to the relational state storage module 107 and stored in the relational state storage module 107 for auditing and subsequent decision-making.

[0128] The consequence decision-making module 105 calculates changes in relationship values ​​through consequence event decisions. The relationship state storage module 107 stores the relationship values, trust values, emotional states, response delay strategies, and response strategy identifiers generated by the consequence event decisions, along with their change records, and provides historical trajectories and current values. The behavior generation and output module 106 reads the relationship values, trust values, emotional states, response delay strategies, and response strategy identifiers generated by the consequence event decisions from the relationship state storage module 107 to generate response results.

[0129] The module scheduling and data bus module 108 is used to coordinate the data flow and calling order between the modules (i.e., modules 101-107), so that each module works in the manner described above, ensuring the overall closed-loop operation of the system.

[0130] like Figure 3 As shown, the human-computer interaction method based on commitment state machines, implemented according to the above-described human-computer interaction system, includes the following steps:

[0131] Step S1: Receive interactive input from the user using the behavior event acquisition module 101 and convert it into standardized behavior events;

[0132] Step S2: Use the commitment identification and modeling module 102 to determine whether the standardized behavioral event constitutes a commitment, and generate a commitment object when a commitment is constituted;

[0133] Step S3: Use the commitment state management module 103 to create the state of the commitment object. At this time, the state of the commitment object is the pending verification state.

[0134] Step S4: Use the verification and judgment module 104 to extract the set of performance conditions from the attributes of the commitment object. The set of performance conditions includes at least one performance condition. When the performance condition is met, output an instruction to the commitment status management module 103 to meet the performance condition, so that the commitment status management module 103 updates the status of the commitment object to the performance status.

[0135] Using the commitment status management module 103, when the validity period of a commitment expires, if the commitment has not yet met the performance determination conditions and the commitment type is a vague commitment, the status of the commitment will be updated to expired; if the commitment type is a rigid commitment, the status will be updated to default. When the commitment is already in a performance state, it will not be rolled back to expired or defaulted.

[0136] Step S5: Using the consequence decision module 105, generate the corresponding consequence event decision based on the current state of the commitment object and the pre-stored consequence mapping rules;

[0137] Step S6: Utilize the behavior generation and output module 106, which is used to generate specific system response behaviors based on the results of the consequence event decision (including relation values, emotional states, response strategy identifiers, total delay, and rejection or cold treatment strategies).

[0138] Table 2 shows a comparison of the technical effects of the prior art and the system of the present invention.

[0139] Table 2: Comparison of Technical Effects

[0140]

[0141] Therefore, the system of the present invention achieves engineered management of commitment fulfillment and breach by structurally modeling commitments in interactive behavior, creating, continuously verifying and managing the validity period of commitments, and dynamically adjusting subsequent behaviors according to the current state. This enables human-computer interaction to have cross-time consistency, realizes a human-computer relationship evolution mechanism with causal consequences, elevates the human-computer relationship evolution from the semantic layer to the system decision layer, and supports parallel management of multiple commitments and multiple roles.

[0142] In summary, the key technical features of the system of the present invention are as follows: the commitment object determines its verification mode identifier during the generation stage; the verification and judgment module performs performance judgment based on the verification mode identifier; the consequence decision module generates structured consequence event decisions based on the performance judgment results; and the behavior generation module generates a system response based on the consequence event decisions, thereby forming a closed-loop mechanism of "commitment generation - verification judgment - status update - consequence decision - behavior output".

[0143] The above description is merely a preferred embodiment of the present invention and is not intended to limit the scope of the invention. Various variations can be made to the above embodiments of the present invention. All simple and equivalent changes and modifications made in accordance with the claims and description of this application fall within the protection scope of the claims of this patent. All aspects not described in detail in this invention are conventional technical content.

Claims

1. A human-computer interaction system based on a commitment state machine, characterized in that, It includes a behavioral event acquisition module, a commitment identification and modeling module, a commitment status management module, a verification and judgment module, a consequence decision-making module, and a behavior generation and output module; The behavior event acquisition module is used to receive interactive input from users and convert it into standardized behavior events; The commitment identification and modeling module is used to determine whether a standardized behavioral event constitutes a commitment, and to generate a commitment object when a commitment is constituted. The commitment state management module is used to create the state of commitment objects and maintain and update the state of commitment objects; The verification and judgment module is set to output an instruction that the performance conditions are met to the commitment status management module when the performance conditions are met, so as to update the status of the commitment object to the performance status. The consequence decision-making module is set to generate corresponding consequence event decisions based on the current state of the commitment object and the pre-stored consequence mapping rules; The behavior generation and output module is used to generate specific system response behaviors based on the results of the consequences of the event decision.

2. The human-computer interaction system based on a commitment state machine according to claim 1, characterized in that, The status of the commitment object includes pending verification status, performance status, default status, and expired status; the commitment status management module maintains and updates the status of the commitment object in response to the verification and judgment module's instruction to meet the performance conditions, the commitment type of the commitment object, and the commitment validity period of the commitment object. The commitment state management module is configured to: when a commitment object is created, it is assigned an initial state, at which point the commitment object is in a state of pending verification. The final states are performance status, default status, and expiration status. Once the commitment object enters the performance status or default status in a judgment cycle, its status will not be rolled back in subsequent judgment cycles. When multiple conditions for updating to the final state are triggered within the same judgment period, the final state is determined in the following priority order: performance state > default state > expiration state.

3. The human-computer interaction system based on a commitment state machine according to claim 2, characterized in that, The verification and judgment module is further configured to: extract a set of performance conditions and a set of default conditions from the attributes of the commitment object, wherein the set of performance conditions includes at least one performance condition and the set of default conditions includes at least one default condition; when a default condition is met, output an instruction to the commitment status management module to update the status of the commitment object to a default status; The commitment status management module first determines whether the performance conditions are met. If they are met, the status of the commitment object is updated to the performance status. If not, it determines whether the breach conditions are met. If they are met, the status of the commitment object is updated to the breach status. If none of the above conditions are met, it determines whether the effective time range of the commitment has expired to determine whether the expiration condition is met. If it is met, the status of the commitment object is updated to the expiration status or the breach status according to the commitment type. If the verification and judgment module receives an instruction that the fulfillment conditions are met, then the fulfillment conditions are met. If the verification and judgment module receives an instruction that the default conditions are met, then the default conditions are met. If the commitment object has not met the performance determination conditions when the validity period of the commitment expires, then the expiration condition is met. When the expiration condition is met, if the commitment type of the commitment object is a rigid commitment, the status will be updated to a default status; if the commitment type of the commitment object is a vague commitment, the status will be updated to an expired status.

4. The human-computer interaction system based on a commitment state machine according to claim 1, characterized in that, Whether a standardized behavioral event constitutes a commitment is determined based on at least one of the following pre-defined commitment criteria: rule matching criteria; or, the classification result output by the semantic classification model is a commitment. The rule matching conditions are keyword matching conditions, semantic template matching conditions, or sentence structure recognition conditions.

5. The human-computer interaction system based on a commitment state machine according to claim 4, characterized in that, A two-stage processing mechanism is used to determine whether a standardized behavioral event constitutes a commitment, which specifically includes: Step A1: When the input natural language interactive content meets any of the rule matching conditions, it is identified as a candidate commitment statement; the rule matching conditions include: hitting the preset commitment keyword set, conforming to the predefined semantic template structure, and satisfying specific commitment sentence structure features; Step A2: Further evaluate the candidate commitment statements by combining the context, confidence threshold, and verifiability rules to determine whether the standardized behavioral event constitutes a commitment. If so, generate a commitment object. When determining whether a standardized behavioral event constitutes a commitment based on the classification result output by the semantic classification model, the semantic classification model includes traditional classification models based on feature vectors; neural network models based on deep learning; and semantic determination models based on large-scale language models. The output of the semantic classification model includes at least one of the following: binary classification results of commitment and non-commitment, commitment confidence, commitment type, and commitment element extraction results.

6. The human-computer interaction system based on a commitment state machine according to claim 1, characterized in that, When a commitment is formed, a commitment object is generated, which specifically includes: modeling the standardized behavioral events that constitute the commitment as a structured commitment object; wherein, the commitment object includes two types of attributes: core attributes and optional extended attributes; The core attributes include: unique identifier of the commitment; commitment subject; commitment content; commitment creation time; and current commitment status. Optional extended attributes include: commitment validity period, set of performance conditions, commitment type, priority, commitment confidence level, and verification mode identifier; When the commitment recognition and modeling module can extract or deduce optional extended attributes from the interactive content, it uses the obtained optional extended attributes to fill them in; otherwise, it uses the default rules or fallback rules to complete the optional extended attributes with default values. The commitment types are classified according to semantic features into: outcome-oriented commitment, frequency-based commitment, relational attitude commitment, and fuzzy commitment; outcome-oriented commitment, frequency-based commitment, and relational attitude commitment are all rigid commitments.

7. The human-computer interaction system based on a commitment state machine according to claim 6, characterized in that, The commitment object includes a verification pattern identifier as an optional extended attribute; the verification pattern identifier is generated based on the commitment type and / or the set of performance conditions; the verification pattern identifier includes full condition satisfaction, key condition satisfaction, and weighted scoring types; When performing verification, the verification and judgment module has the following characteristics: if the verification mode is identified as "full condition satisfaction", then all performance conditions are met within the validity period of the commitment, and the performance conditions are considered to be met; if the verification mode is identified as "key condition satisfaction", then key conditions are pre-marked among multiple performance conditions, and the performance conditions are considered to be met as long as the key conditions are met; if the verification mode is identified as "weighted scoring", then different weight parameters are assigned to each performance condition, and the performance conditions are considered to be met by accumulating the score and whether it reaches a preset threshold.

8. The human-computer interaction system based on a commitment state machine according to claim 1, characterized in that, The consequence event decision includes: increasing or decreasing relationship value and trust value; adjusting emotional state; response delay strategy; rejection or cold treatment strategy; and generating response strategy identifier; wherein, the probability of rejection or cold treatment strategy corresponds to relationship value, and response delay strategy is used to superimpose with other delays to obtain total delay; When the commitment status is in default, mandatory consequence events are generated first as the consequence event decision; When the commitment status is expired, a lightweight consequence event is generated, or no mandatory consequence event is generated, as the consequence event decision. When the commitment status is in the fulfillment status, a positive feedback consequence event is generated as the consequence event decision; The behavior generation and output module generates specific system response behaviors, including: first, determining whether a response strategy identifier exists; if it exists, generating a text response based on the response strategy identifier using the text generation module; if it does not exist, further determining whether a rejection or cold-handing strategy exists; if it exists, executing a rejection or cold-handing response; if it does not exist, generating a text response based on the emotional state; and then, performing a delayed response based on the total delay.

9. The human-computer interaction system based on a commitment state machine according to claim 1, characterized in that, It also includes a relational state storage module and a module scheduling and data bus module. The relational state storage module is used to store the commitment object and its state, the historical results of whether the performance conditions are met, the relational value and its change records. The module scheduling and data bus module is used to coordinate the data flow and calling order of the behavior event acquisition module, commitment identification and modeling module, commitment state management module, verification and judgment module, consequence decision module, behavior generation and output module and relational state storage module.

10. A human-computer relationship dynamics interaction method based on commitment state machines, characterized in that, Includes the following steps: Step S1: Receive interactive input from the user using the behavior event acquisition module and convert it into standardized behavior events; Step S2: Use the commitment identification and modeling module to determine whether a standardized behavioral event constitutes a commitment, and generate a commitment object when a commitment is constituted; Step S3: Use the commitment state management module to create the state of the commitment object. At this time, the state of the commitment object is the pending verification state. Step S4: Using the verification and judgment module, when the performance conditions are met, output the instruction that the performance conditions are met to the commitment status management module, so that the commitment status management module updates the status of the commitment object to the performance status. Step S5: Using the consequence decision module, generate corresponding consequence event decisions based on the current state of the commitment object and the pre-stored consequence mapping rules; Step S6: Utilize the behavior generation and output module, which is used to generate specific system response behaviors based on the results of the consequence event decision.

Images