Virtual resource allocation method, device, storage medium and program product

Abstract

Embodiments of the present application provide a virtual resource allocation method, device, storage medium and program product. In the method, a user basic portrait can be obtained, a service intent representation is identified from user dialogue content by a large language model, a target vertical service domain to which the service intent belongs is determined in cooperation with service nodes of each vertical service domain, and target interaction data of the user in the domain is obtained; an identity attribute graph of the user in the target vertical service domain is constructed based on an identity attribute inference model according to the basic portrait, the target interaction data and the service intent representation, a relationship graph reflecting the adaptation degree of resources and the user is generated in combination with the service intent representation, and target virtual resources are filtered and distributed according to the relationship graph. In this way, multi-domain collaborative negotiation decision of service intent attribution is realized, the limitations of center-end unilateral decision are broken, the intent attribution misjudgment rate is reduced, dynamic and accurate matching of virtual resources and user demand is realized, and the resource distribution efficiency is improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a virtual resource allocation method, device, storage medium, and program product. Background Technology

[0002] As internet service platforms expand their service scenarios and dimensions, they typically integrate service nodes from multiple vertical service domains and enhance user experience by distributing virtual resources to platform users. Currently, the industry generally uses the following distribution method for these virtual resources: the platform distributes virtual resources indiscriminately to all users without distinguishing between individual user differences and actual service needs. In this model, the distribution decisions for virtual resources are completely disconnected from users' actual service requirements. This not only results in significant wasted platform computing and transmission resources and the virtual resources themselves, but also causes unnecessary interaction disruptions for users with no corresponding service needs, thus reducing the user experience.

[0003] In summary, existing technologies suffer from the inability to achieve dynamic and accurate matching of virtual resources based on users' real-time interactive intentions, resulting in low matching efficiency and accuracy in virtual resource distribution. Summary of the Invention

[0004] This application provides a virtual resource allocation method, device, storage medium, and program product to achieve dynamic and accurate matching between virtual resources and user needs.

[0005] This application provides a virtual resource allocation method applied to a target agent deployed in a target service platform. The target agent communicates and interfaces with service nodes in multiple vertical service domains within the target service platform. The method includes: responding to a user-initiated session and obtaining a basic profile of the user; wherein the basic profile is obtained by fusing the user's attribute data, spatiotemporal data, and historical interaction data; during multiple rounds of dialogue with the user, obtaining the target dialogue content input by the user in the current round, and identifying the user's service intent representation from the target dialogue content based on a large language model associated with the target agent; determining the target vertical service domain to which the service intent belongs based on the service intent representation and in collaboration with service nodes in each vertical service domain; and further determining the target vertical service domain from the... The service node corresponding to the target vertical service domain acquires the user's target interaction data within the target vertical service domain; based on the identity attribute reasoning model, and according to the basic profile, the target interaction data, and the service intent representation, an identity attribute graph of the user within the target vertical service domain is constructed; based on the resource adaptation quantification model, and according to the service intent representation and the identity attribute graph, a relationship graph between each candidate virtual resource within the target vertical service domain and the user is constructed, the relationship graph reflecting the adaptation degree between the candidate virtual resources and the user; based on the adaptation degree reflected by the relationship graph, at least one target virtual resource that meets the adaptation degree condition is selected from the candidate virtual resources, and the at least one target virtual resource is distributed to the user's terminal device.

[0006] Optionally, determining the target vertical service domain to which the service intent belongs based on the service intent representation and the collaborative efforts of service nodes on each vertical service domain includes: extracting features from the service intent representation based on the large language model to obtain a standardized semantic feature vector, generating an intent verification request carrying the standardized semantic feature vector and the user's identifier, and distributing the intent verification request in parallel to the service nodes corresponding to each vertical service domain; receiving the domain matching response returned by each service node for the intent verification request, wherein the domain matching response returned by any service node includes: the local matching degree between the vertical service domain corresponding to the service node and the service intent representation and a matching basis feature set, wherein the local matching degree is calculated by the service node based on a locally deployed domain intent matching model and a local rule base; determining a set of candidate vertical service domains whose local matching degree meets preset conditions based on the domain matching responses returned by each service node, and if there is only one candidate vertical service domain in the set of candidate vertical service domains, then that candidate vertical service domain is determined as the target vertical service domain.

[0007] Optionally, the process further includes: initiating a multi-round collaborative negotiation process when at least two candidate vertical service domains in the candidate vertical service domain set have a local matching degree difference less than a preset difference threshold; in each iteration of the multi-round collaborative negotiation process, distributing a collaborative negotiation request to the service node corresponding to each candidate vertical service domain, the collaborative negotiation request carrying the matching basis feature set, updated local matching degree, domain adaptation feature set, and service resource readiness status data of the remaining candidate vertical service domains; receiving the updated local matching degree and matching basis feature set recalculated and returned by the service node of each candidate vertical service domain based on the collaborative negotiation request; the multi-round collaborative negotiation process stops iteration when any of the following termination conditions are met: Condition 1: after iteration, in the candidate vertical service domain set, there is a unique candidate vertical service domain whose updated local matching degree is greater than the preset difference threshold compared with the updated local matching degree of all other candidate vertical service domains in the set, and this candidate vertical service domain is determined as the target vertical service domain; Condition 2: the iteration round reaches the preset maximum negotiation round, and the candidate vertical service domain with the highest updated local matching degree is selected from the candidate vertical service domain set and determined as the target vertical service domain.

[0008] Optionally, based on the identity attribute reasoning model, and according to the basic profile, the target interaction data, and the service intent representation, an identity attribute graph of the user within the target vertical service domain is constructed, including: extracting the user's basic attribute features from the basic profile, extracting the user's historical behavior features from the target interaction data, and extracting the user's real-time demand features from the service intent representation based on the identity attribute reasoning model; inferring the user's supply and demand identity attributes within the target vertical service domain based on the basic attribute features, the historical behavior features, and the real-time demand features, the supply and demand identity attributes include: service supplier attributes and service demander attributes; and constructing the identity attribute graph with the supply and demand identity attributes as the core nodes and the basic attribute features, historical behavior features, and real-time demand features as related nodes.

[0009] Optionally, based on the resource adaptation metric model, and according to the service intent representation and the identity attribute graph, a relationship graph between each candidate virtual resource and the user within the target vertical service domain is constructed, including: encoding each node in the service intent representation and the identity attribute graph into a high-dimensional user feature vector, and encoding the attribute information and applicable scenario information of each candidate virtual resource into a high-dimensional resource feature vector; mapping the user high-dimensional feature vector and each resource high-dimensional feature vector to the same high-dimensional feature vector space, and calculating the cosine similarity between the user high-dimensional feature vector and each resource high-dimensional feature vector; determining the fit between each candidate virtual resource and the user based on the cosine similarity, and constructing the relationship graph based on the fit.

[0010] Optionally, based on the fit degree reflected in the relationship graph, at least one target virtual resource that meets the fit degree condition is selected from the candidate virtual resources, including: for any candidate virtual resource, obtaining the user's historical reception frequency and historical conversion data for similar virtual resources in the target vertical service domain within a preset historical time window; calculating the user's marginal utility value for the current candidate virtual resource based on a pre-trained utility decay curve model and the historical reception frequency and historical conversion data; and determining the candidate virtual resource as the target virtual resource if the marginal utility value is greater than a preset minimum efficiency threshold and the fit degree of the candidate virtual resource meets the fit degree condition.

[0011] Optionally, before selecting at least one target virtual resource that meets the suitability criteria from the candidate virtual resources based on the suitability reflected in the relationship graph, the method further includes: collecting runtime context metadata of the user's terminal device, wherein the runtime context metadata includes at least one of application version information, system version information, network status information, and geographical location information; and performing environmental suitability verification on each candidate virtual resource based on the runtime context metadata, and eliminating candidate virtual resources that fail the environmental suitability verification.

[0012] This application also provides an electronic device, including: a memory and a processor; wherein the memory is used to: store one or more computer instructions; and the processor is used to execute the one or more computer instructions to: perform the steps in the virtual resource allocation method.

[0013] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, enables the processor to implement the steps in the virtual resource allocation method.

[0014] This application also provides a computer program product, including a computer program / instruction, which, when executed by a processor, enables the processor to implement the steps in the virtual resource allocation method.

[0015] In this embodiment, a basic user profile is obtained, and service intent representations are identified from user dialogue content using a large language model. Collaboration with service nodes in various vertical service domains determines the target vertical service domain to which the service intent belongs, and target interaction data of the user within that domain is obtained. Based on an identity attribute reasoning model, an identity attribute graph of the user within the target vertical service domain is constructed according to the basic profile, target interaction data, and service intent representations. This graph, combined with the service intent representations, generates a relationship graph reflecting the suitability between resources and users. Target virtual resources are then selected and distributed based on this relationship graph. This approach achieves multi-domain collaborative negotiation and decision-making regarding service intent attribution, breaking the limitations of unilateral decision-making at the central end, reducing the misjudgment rate of intent attribution, realizing dynamic and accurate matching of virtual resources with user needs, and improving resource distribution efficiency. Attached Figure Description

[0016] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 A flowchart illustrating a virtual resource allocation method provided for an exemplary embodiment of this application; Figure 2 A schematic diagram of an electronic device provided for an exemplary embodiment of this application. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0018] 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, and displayed data) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use, and processing of such data must comply with the relevant laws, regulations, and standards of the relevant countries and regions, and corresponding access points are provided for users to choose to authorize or refuse. In addition, the various models involved in this application (including but not limited to language models or large models) comply with relevant laws and standards.

[0019] As internet service platforms expand their service scenarios and dimensions, they typically integrate service nodes from multiple vertical service domains and enhance user experience by distributing virtual resources to platform users. Currently, the industry generally uses the following distribution method for these virtual resources: the platform distributes virtual resources indiscriminately to all users without distinguishing between individual user differences and actual service needs. In this model, the distribution decisions for virtual resources are completely disconnected from users' actual service requirements. This not only results in significant wasted platform computing and transmission resources and the virtual resources themselves, but also causes unnecessary interaction disruptions for users with no corresponding service needs, thus reducing the user experience.

[0020] In summary, existing technologies suffer from the inability to achieve dynamic and accurate matching of virtual resources based on users' real-time interactive intentions, resulting in low matching efficiency and accuracy in virtual resource distribution.

[0021] To address the aforementioned technical issues, this application embodiment achieves accurate identification of user service intent through a multi-domain collaborative intent attribution determination mechanism, reducing the intent misjudgment rate in multi-domain scenarios; by combining real-time user dialogue intent with an identity attribute graph constructed from domain data, dynamic perception of user needs is achieved, solving the problem of lagging updates in traditional static user profiles; and through the adaptation and quantification of high-dimensional vector space, accurate matching of virtual resources and user needs is achieved, effectively reducing ineffective resource consumption and improving the user's platform experience.

[0022] The technical solutions provided by the various embodiments of this application are described in detail below with reference to the accompanying drawings.

[0023] Figure 1 This is a flowchart illustrating a virtual resource allocation method provided as an exemplary embodiment of this application. The virtual resource allocation method is applied to a target intelligent agent deployed in a target service platform, and the target intelligent agent communicates and interfaces with service nodes of multiple vertical service domains in the target service platform.

[0024] Among them, the target service platform refers to an internet service platform that integrates multiple vertical life service scenarios, such as a comprehensive life service platform that integrates real estate, recruitment, housekeeping, local business and other services; the target service platform is divided into multiple independent vertical service domains according to service scenarios, and each vertical service domain corresponds to a standardized service scenario.

[0025] Vertical service domains refer to independent service domains within the target service platform, categorized by service type and scenario, including but not limited to: real estate service domains, recruitment service domains, housekeeping service domains, local business service domains, and used car service domains. Each vertical service domain has an independent service node, which serves as the storage and execution unit for service data, virtual resources, and service rules within that domain. The target intelligent agent, or AI (Artificial Intelligence) agent, is an intelligent agent program deployed within the target service platform, possessing capabilities such as environmental awareness, multi-turn natural language dialogue interaction, user intent recognition, cross-node data collaboration, and decision-making execution. The target intelligent agent can establish bidirectional communication with service nodes in each vertical service domain through pre-defined standardized APIs (Application Programming Interfaces), granting it permissions to retrieve authorized data, issue service commands, and synchronize status information from each service node.

[0026] The virtual resources can be any type of digital virtual resources allocated to each vertical service domain within the target service platform. This embodiment does not impose any restrictions, and can be any type such as virtual rights or virtual items. For example, virtual resources may include, but are not limited to, at least one of the following: digital vouchers for platform service deductions, digital vouchers for service rights redemption, membership service permissions, service process priority vouchers, platform service qualifications, and customized service quotas.

[0027] like Figure 1 As shown, the virtual resource allocation method may include the following steps: Step 11: Respond to user-initiated conversations and obtain the user's basic profile; the basic profile is obtained by integrating the user's attribute data, spatiotemporal data, and historical interaction data.

[0028] Step 12: During the multi-round dialogue with the user, obtain the target dialogue content input by the user in the current round, and identify the user's service intent representation from the target dialogue content based on the large language model associated with the target agent. Determine the target vertical service domain to which the service intent belongs based on the service intent representation and the service nodes on each vertical service domain, and obtain the user's target interaction data in the target vertical service domain from the service nodes corresponding to the target vertical service domain.

[0029] Step 13: Based on the identity attribute reasoning model, construct the user's identity attribute graph within the target vertical service domain according to the basic profile, target interaction data, and service intent representation.

[0030] Step 14: Based on the resource adaptation quantification model, construct a relationship graph between each candidate virtual resource and user within the target vertical service domain according to the service intent representation and identity attribute graph. The relationship graph is used to reflect the adaptation degree between the candidate virtual resources and users.

[0031] Step 15: Based on the fit degree reflected in the relationship graph, select at least one target virtual resource that meets the fit degree condition from each candidate virtual resource, and distribute at least one target virtual resource to the user's terminal device.

[0032] In this embodiment, when a user initiates a conversation by entering the intelligent customer service conversation page through the terminal entry point of the target service platform, such as an APP, mini-program, or web page (including inputting text, voice, clicking shortcuts, etc.), the target intelligent agent can respond to the user's conversation and obtain the user's basic profile.

[0033] Specifically, a pre-generated basic profile for a user can be retrieved from the target service platform's user profiling system using the user's identifier. This basic profile is obtained by integrating the user's attribute data, spatiotemporal data, and historical interaction data. Attribute data refers to the user's inherent attribute information, including but not limited to at least one of the following: age, gender, real-name authentication status, membership level, account registration duration, and contact information linked to the account. Spatiotemporal data refers to the user's geographic location and time-related behavioral data, including but not limited to at least one of the following: the user's permanent residence city, current location city, frequently logged-in time periods, platform active time periods, and geographic location change records. Historical interaction data refers to the user's historical behavioral data across all vertical service domains of the target service platform, including but not limited to at least one of the following: the user's historical browsing history, historical search history, historical consultation history, historical order history, historical virtual resource acquisition and usage history, and historical collection history.

[0034] Among them, a preset feature fusion algorithm can be used to extract and fuse features from attribute data, spatiotemporal data and historical interaction data to generate a standardized user basic feature vector. Specifically, feature splicing, normalization processing and weight allocation can be used to achieve this. For example, higher weight can be assigned to the user's recent active data and lower weight can be assigned to the long-term historical data to ensure that the basic profile can reflect the user's long-term basic characteristics.

[0035] In this embodiment, during multiple rounds of dialogue with the user, the target dialogue content input by the user in the current round can be obtained. The target dialogue content includes, but is not limited to, the text content input by the user, the text content after speech-to-text translation, and the text content corresponding to the shortcut commands clicked by the user. The obtained target dialogue content is then input into the associated large language model. The large language model associated with the target agent can be deployed in any location, such as on the target service platform, or on a server outside the target service platform but connected to it, etc.

[0036] Large language models can be used to identify user service intent representations from target dialogue content. Specifically, based on pre-trained and fine-tuned intent classification capabilities, combined with multi-turn dialogue content within the context, user service intents can be categorized to determine their specific needs, such as "rental consultation," "looking for cleaning services," or "job consultation." The identified service intents are then converted into standardized service intent representations, which are computer-processable feature vectors containing feature information such as the service category, intent keywords, urgency of the need, and timeliness of the need.

[0037] Subsequently, based on the large language model, the target vertical service domain to which the service intent belongs can be determined in collaboration with the service nodes on each vertical service domain according to the service intent representation.

[0038] For example, if a user inputs the target dialogue "I want to rent a two-bedroom apartment in city A," the large language model identifies the service intent as "rental needs, location: city A, apartment type: two-bedroom." The target agent can then send this service intent representation to service nodes in various vertical service domains. The service node in the real estate service domain returns a matching score of 98, while the matching scores of other service nodes are all below 30. Therefore, the target vertical service domain is determined to be the real estate service domain. This multi-domain collaborative negotiation mechanism, unlike the traditional unilateral decision-making method through the central decision-making module of the target service platform, breaks through the limitations of this central unilateral decision-making, enabling a more accurate determination of the target vertical service domain to which the service intent belongs, and reducing the misjudgment rate of intent attribution.

[0039] During the collaborative confirmation of the target vertical service domain, the target intelligent agent deployed on the platform's central side is used for standardized semantic extraction of intents, scheduling of collaborative processes, and convergence of arbitration results. It does not require storing or acquiring the full set of service rules, sensitive user raw data, and core parameters of the intent model within each vertical service domain, thus clearly defining the boundaries of responsibility between the central side and the vertical domains. Each service node in each vertical service domain deploys its own domain-specific intent matching model, local service rule base, and domain-specific user data storage unit, only outputting publicly available, non-sensitive matching features and matching degree results. Core data within the domain does not flow across domains throughout the entire process, addressing cross-domain data privacy and compliance issues at the architectural level.

[0040] Based on its associated large language model, the target intelligent agent performs standardized semantic transformation on the extracted user service intent representation, generating a cross-domain unified and unambiguous standardized semantic expression. This eliminates the matching bias caused by differences in service terms, intent systems, and semantic definitions among different vertical service domains, ensuring that the matching results returned by each vertical service domain are horizontally comparable, and providing a unified mathematical and semantic foundation for cross-domain collaborative judgment.

[0041] The target intelligent agent distributes the standardized service intent information to the service nodes corresponding to each vertical service domain. Each service node, in its local environment, autonomously verifies the matching degree between the service intent and the service scope of its domain based on its domain-specific service rule base, domain-specific intent matching model, and user domain-specific data, and generates the corresponding matching result information.

[0042] By delegating the professional verification process for intent matching entirely to the local vertical service domain, the platform can deeply adapt to the service rules and intent systems of each vertical domain, significantly improving the accuracy of intent recognition in professional and niche scenarios. Furthermore, core service rules and sensitive user data remain within the domain without crossing boundaries, outputting only non-sensitive matching results, fundamentally resolving data privacy and compliance issues associated with centralized recognition solutions. Simultaneously, when adding a new vertical service domain, the platform only needs to complete the local deployment of the corresponding service node, eliminating the need for full retraining of the central target agent and associated large language model, greatly reducing the platform's service expansion costs and demonstrating strong scalability.

[0043] After receiving the matching results from the service nodes of each vertical service domain, the target agent performs a global comparison and convergence judgment on the matching results of each vertical service domain based on preset judgment rules, and finally determines the unique target vertical service domain with the highest matching degree to the user's service intent. Through global convergence on the central side, a unified decision on distributed verification results is achieved, ensuring the uniqueness and certainty of the intent attribution judgment result.

[0044] When the matching results returned by multiple vertical service domains are ambiguous (i.e., the difference in matching degree between multiple vertical domains does not reach the preset unique judgment threshold), the target agent can initiate a multi-round collaborative ambiguity resolution process. Through the cross-sharing of limited non-sensitive matching basis information among candidate vertical service domains, the service nodes of each candidate domain re-complete localized matching verification and matching degree update. The target agent then completes the final convergence judgment based on the updated matching results. Under the premise of strictly adhering to data privacy compliance requirements, the precise resolution of cross-domain ambiguous intents is achieved through limited cross-information collaboration, further improving the accuracy of intent attribution determination in complex scenarios.

[0045] Once the target vertical service domain is determined, a user data retrieval request can be initiated to the service node corresponding to the target vertical service domain through a standardized API interface to retrieve the user's target interaction data within the target vertical service domain; the target interaction data is the user's behavioral data in the specific target service scenario corresponding to the target vertical service domain.

[0046] Taking the real estate services domain as an example, target interaction data may include a user's historical rental browsing history, property collection history, viewing history, rental consultation history, historical rental order history, landlord identity verification status, and property posting history. Taking the housekeeping services domain as an example, target interaction data may include a user's historical housekeeping service order history, service preferences, service address, service frequency, and historical consultation history.

[0047] In this embodiment, an identity attribute inference model can be used to construct a user's identity attribute graph within a target vertical service domain, based on a basic profile, target interaction data, and service intent representation. The identity attribute inference model can be a pre-trained machine learning model or any other model, and can be constructed using algorithms such as graph neural networks, random forests, and deep neural networks. Optionally, the training samples for the identity attribute inference model can be historical user data, historical dialogue data, and historical business conversion data from various vertical service domains within the target service platform, and the training labels can be the user's standard identity attribute labels within the corresponding vertical service domain.

[0048] Next, the virtual resource and user adaptation quantification step, i.e., step 14, can be executed. This step aims to quantitatively evaluate the adaptability of available virtual resources within the current vertical service domain based on the user's real-time service intent and contextualized identity attributes, constructing an interpretable adaptation relationship graph to provide a quantitative basis for the final resource selection. Specifically, based on the resource adaptation quantification model, a relationship graph between each candidate virtual resource and the user within the target vertical service domain can be constructed according to the service intent representation and identity attribute graph. The resource adaptation quantification model can be a pre-trained machine learning model or any other type of model, constructed using algorithms such as graph neural networks, factorization machines, or deep cross-referencing networks. Optionally, the training samples for the resource adaptation quantification model can be historical virtual resource distribution data, user conversion data, and user feedback data from each vertical service domain within the target service platform, with the training label being the actual adaptability of the virtual resource and the user (calculated comprehensively based on indicators such as claim rate, usage rate, and conversion effect).

[0049] For example, for tenants in City A mentioned above, the resource matching quantification model calculates the matching degree of candidate virtual resources: the intent matching degree of "City A rental coupon" is 95, the identity matching degree is 90, the scenario matching degree is 100, and the total matching degree score is 94; the total matching degree score of "new tenant's first order discount coupon" is 88; and the total matching degree score of "landlord's free listing coupon" is 10. Finally, a relationship graph between the user and each candidate virtual resource is constructed to clarify the matching degree score of each resource and the matching status of each dimension.

[0050] Based on the above, at least one target virtual resource that meets the adaptation criteria can be selected from among the candidate virtual resources according to the adaptation degree reflected in the relationship graph, and the at least one target virtual resource can be distributed to the user's terminal device.

[0051] The system can sort candidate virtual resources based on their suitability scores as reflected in the relationship graph, set a preset suitability threshold, and select candidate virtual resources with suitability scores greater than or equal to the threshold as target virtual resources that meet the suitability criteria. Based on the selected target virtual resource, a resource description in natural language can be generated, including details, usage rules, validity period, and applicable scenarios. This description is sent to the user through a dialogue interface, while simultaneously asking if the user wants to claim the virtual resource. After receiving a clear confirmation from the user, a resource distribution instruction can be sent to the service node of the target vertical service domain. The service node completes the distribution of the virtual resource, sending it to the user's platform account and simultaneously synchronizing the distribution result to the target agent. The target agent can then inform the user of the successful distribution through a dialogue interface and guide the user in using the resource.

[0052] In this way: On the one hand, virtual resource distribution is completed through user-initiated interactive scenarios, replacing the traditional indiscriminate pop-up windows and SMS push modes, without interrupting the user's normal platform usage flow. On the other hand, multi-turn dialogue interaction based on target intelligent agents enables real-time perception of user intent, replacing the traditional targeted distribution mode based on static historical data. It can match virtual resources based on the user's current service needs, solving the problem of lagging updates to static user profiles and their inability to match dynamic user needs, significantly improving the accuracy and conversion efficiency of virtual resource distribution.

[0053] On the one hand, the collaboration between the target intelligent agent and service nodes in various vertical service domains forms a multi-domain collaborative negotiation mechanism. Based on this mechanism, the limitations of unilateral decision-making at the central end are broken, the misjudgment rate of intent attribution is reduced, and dynamic and accurate matching of virtual resources and user needs is achieved, thereby improving resource distribution efficiency.

[0054] On the one hand, basic user profiles are used to cover basic user characteristics. On the other hand, target interaction data from the target vertical service domain is used to supplement deep features in the service scenario. Combined with service intent representation, an identity attribute graph is constructed to more accurately reflect the user's identity and needs in specific service scenarios, avoiding the problems of full data dimensional redundancy and poor scenario adaptability in traditional methods.

[0055] On the one hand, by constructing and matching the relationship graph between users and virtual resources through a resource adaptation quantification model, the traditional virtual resource allocation mode based on manual rules is replaced. This can adapt to complex user needs and service scenarios, while significantly reducing the cost of manual operation, reducing the ineffective consumption of platform computing and transmission resources, and avoiding the waste of virtual resources.

[0056] In some optional embodiments, the aforementioned embodiment's "acquiring the target dialogue content input by the user in the current round during multiple rounds of dialogue with the user, and identifying the user's service intent representation from the target dialogue content based on the large language model associated with the target agent" can be implemented in the following ways: In each round of the multi-round dialogue, the target dialogue content for the current round is obtained, and the intent features for the current round are extracted using a large language model. The intent features for the current round are then fused and iteratively integrated with the service intent representations from previous rounds to update the service intent representation for the current round. When a cross-vertical service domain offset is detected in the updated service intent representation, the target vertical service domain to which the service intent belongs is redefined, and the target interaction data within the corresponding target vertical service domain is obtained.

[0057] In some alternative embodiments, the aforementioned embodiment of "obtaining the target dialogue content input by the user in the current round during multiple rounds of dialogue with the user, and identifying the user's service intent representation from the target dialogue content based on the large language model associated with the target agent" can be implemented in the following ways: The system acquires the target dialogue content input by the user in the current round and the historical dialogue content within a preset round threshold in the current conversation window. It adds corresponding role and time tags to each line of dialogue content in both the historical and target dialogues, then concatenates them temporally to generate a dialogue context sequence. This sequence is then input into a large language model, where the encoder layer performs global semantic encoding to generate a global semantic feature vector covering the entire dialogue semantics. Simultaneously, the large language model extracts core elements associated with the service intent from the dialogue context sequence. These core elements include at least one of the following: service domain entity, constraint entity, and intent type entity.

[0058] Based on the core elements of global semantic feature vectors and service intent association, a large language model is used to perform multi-level classification of user service intents and their corresponding vertical service domains, obtaining the matching probability scores of each candidate service intent and determining the target service intent with the highest matching probability. Based on the target service intent and the core elements of service intent association, a user service intent representation is generated, which includes structured representation and vectorized representation. The structured representation is standardized service structured data used for service rule matching and manual backtracking. The vectorized representation is a dense semantic feature vector with a fixed dimension, and its dimension is consistent with the feature vector dimension of the basic profile, used for subsequent feature fusion and quantization calculation.

[0059] In this way, the user's service intent can be accurately located, solving the problem of incorrect service intent recognition caused by vague user expressions and confusion of multiple intents.

[0060] In some optional embodiments, the "determining the target vertical service domain to which the service intent belongs based on the service intent representation and the collaborative efforts of service nodes on each vertical service domain" in the aforementioned embodiments can be specifically implemented through steps R1 to R3. This embodiment adopts a collaborative verification architecture of target agent + distributed domain service nodes, replacing the traditional approach based on a single central model, and solves the problem of domain affiliation errors caused by the poor rule adaptability of the single central model to subdivided service domains, ambiguous cross-domain intent boundaries, and delayed service rule updates in multi-vertical service domain scenarios. Specifically: Step R1: Based on the large language model, feature extraction is performed on the service intent representation to obtain a standardized semantic feature vector. An intent verification request carrying the standardized semantic feature vector and the user's identifier is then generated and distributed in parallel to the service nodes corresponding to each vertical service domain. The standardized semantic feature vector refers to the fixed-dimensional dense numerical vector output after feature extraction by the large language model; it is the digital carrier of the core semantics of the user's service intent.

[0061] Step R2: Receive the intra-domain matching response returned by each service node in response to the intent verification request. The intra-domain matching response returned by any service node includes: the local matching degree between the vertical service domain corresponding to the service node and the service intent representation and the matching basis feature set. The local matching degree is calculated by the service node based on the locally deployed intra-domain intent matching model and local rule base.

[0062] The domain-specific intent matching model is a lightweight semantic matching model fine-tuned from massive historical business dialogue data and intent annotation data of the corresponding vertical service domain. Compared with the central large language model, it has a higher recognition accuracy for the subdivided intents, terms, and contextual expressions of this service domain, and can calculate the semantic similarity score between the standardized semantic feature vector and the standard intent library of this domain. The local rule base is a set of service rules maintained by the corresponding vertical service domain, including the domain service keyword library, intent entity matching rules, scenario blacklist and whitelist rules, and user domain activity weight rules, etc. It can calculate the rule hit score between the core elements of the service intent representation and the service rules of this domain.

[0063] Based on a preset weighting ratio, the semantic similarity score and rule hit score are weighted and summed. The weighted sum is then adjusted by considering the user's historical activity in this domain, ultimately yielding the local matching score. A higher local matching score indicates a higher degree of compatibility between the vertical service domain and the user's service intent.

[0064] Among them, the matching basis feature set is the full traceable basis for this matching calculation, including semantic similarity details, service rule details, keyword matching results, and user's historical activity weight in this domain, which is used for subsequent multi-domain collaborative negotiation.

[0065] Step R3: Based on the intra-domain matching response returned by each service node, determine the set of candidate vertical service domains whose local matching degree meets the preset conditions. If there is only one candidate vertical service domain in the set of candidate vertical service domains, then determine the candidate vertical service domain as the target vertical service domain.

[0066] This approach achieves two key benefits: First, it replaces the unified classification model of a single central model. Service nodes in each vertical service domain complete the matching based on their domain-specific models and rules, demonstrating stronger adaptability to the domain's segmented service scenarios, terminology, and boundary-based intents. This fundamentally solves the problems of lagging updates to segmented service rules and ambiguous cross-domain intent boundaries in multi-service domain platforms, leading to incorrect judgments. It is particularly effective for dialogues with ambiguous user expressions and multiple conflicting requests. Second, it introduces service resource readiness data during the collaborative negotiation process. This not only completes the semantic determination of the service domain to which the intent belongs but also ensures that the final target vertical service domain has corresponding distributable virtual resources and service acceptance capabilities, avoiding invalid matching problems such as "the intent is correctly determined, but the target domain has no corresponding resources to distribute."

[0067] Furthermore, this embodiment addresses the scenario where multiple candidate vertical service domains have similar matching degrees, making it impossible to uniquely determine the target vertical service domain. A multi-round collaborative negotiation process is designed, and the specific implementation is as follows: ① In this embodiment, the triggering condition for the multi-round collaborative negotiation process is: at least two candidate vertical service domains in the candidate vertical service domain set have a local matching degree difference less than a preset difference threshold. Here, the local matching degree refers to the initial local matching degree returned by the service nodes of each candidate vertical service domain mentioned above. The determination of the triggering condition can be performed according to the following rules: The first step is to sort all the candidate vertical service domains in the candidate vertical service domain set in descending order of their initial local matching degree. In this embodiment, the "ranked higher" specifically refers to all the candidate vertical service domains included in the candidate vertical service domain set after the above descending sort (i.e., candidate vertical service domains whose initial local matching degree meets the preset candidate domain entry threshold and have effective service response capabilities).

[0068] The second step involves performing a judgment based on the number of candidate vertical service domains in the candidate vertical service domain set, categorized by scenario. If any of the following judgment conditions are met, the triggering condition is deemed met, and a multi-round collaborative negotiation process is initiated: Scenario 1: When the candidate vertical service domain set contains two candidate vertical service domains, the absolute difference between the initial local matching degree of the two candidate vertical service domains after sorting is less than the preset difference threshold. Scenario 2: When the candidate vertical service domain set contains 3 or more candidate domains, the absolute difference between the initial local matching degree of any two top-ranked candidate vertical service domains after sorting is less than the preset difference threshold.

[0069] The preset difference threshold can be set to any value based on the number of vertical service domains of the target service platform or the intent discrimination accuracy requirements of the service scenario. The smaller the threshold, the higher the discrimination accuracy requirement for intent matching.

[0070] ② Single-round iteration execution rules for multi-round collaborative negotiation processes: In this embodiment, the multi-round collaborative negotiation process takes the target intelligent agent as the global scheduling subject and the service nodes of each candidate vertical service domain as independent decision-making subjects. Each iteration of the multi-round collaborative negotiation process performs the following operations: Operation 1, Cooperative Negotiation Request Generation and Distribution: The target agent generates a cooperative negotiation request, which carries the full decision data of the candidate vertical service domains in this iteration, excluding the receiving node itself. This includes the matching basis feature set, the updated local matching degree, the domain adaptation feature set, and the service resource readiness status data. The target agent distributes the generated cooperative negotiation request one-to-one in parallel to the service nodes corresponding to each candidate vertical service domain.

[0071] The complete definitions of each data field are as follows: **Matching Basis Feature Set:** This is the core basis for calculating the local matching degree of the corresponding candidate domain service node, including the intent keyword hit set, semantic feature matching fragments, local service rule hit items, and user domain feature matching items. **Updated Local Matching Degree:** This is the matching degree value recalculated and output by the corresponding candidate domain service node in the previous iteration; in the first iteration, this data is the initial local matching degree returned by the service node mentioned above. **Domain-Specific Adaptation Feature Set:** This is the user-personalized adaptation feature set related to the current user's service intent within the corresponding candidate vertical service domain, including the user's historical interaction preferences, resource usage records, identity and permission tags, and historical performance data within that domain.

[0072] Service resource readiness status data: Real-time status data of service resources that can respond to the current user's service intent in the service nodes of the corresponding candidate vertical service domain, including the number of available resources, the resource effective time interval, the resource admission condition matching status, and the resource call chain readiness status.

[0073] Operation 2, Distributed Independent Calibration Calculation: After receiving the collaborative negotiation request, the service nodes of each candidate vertical service domain, based on the locally deployed domain intent matching model and local rule base, combined with the full decision data of the other candidate domains received, re-evaluate the adaptability of the current service intent with the local domain, complete the calibration update of the local matching degree, and generate the updated local matching degree and the updated matching basis feature set for this round of iteration.

[0074] In this embodiment, the calibration logic of the service node is as follows: based on the matching criteria feature set of the other candidate domains, supplement the identification of semantic features in the current service intent that are not covered by the initial matching of this domain, combine the service resource readiness status of this domain and the user domain adaptation features, adjust the weight coefficients of each dimension of intent matching, and recalculate the local matching degree; during the calibration process, the target agent does not interfere with the independent calculation process of each service node, but is only responsible for information synchronization to ensure the professionalism and independence of the decision-making of each vertical domain.

[0075] Operation 3, Iteration Result Collection: The target agent receives the iteration results returned by the service nodes of each candidate vertical service domain in parallel, namely the updated local matching degree and the matching basis feature set, and completes the single iteration loop.

[0076] The special execution rules for the first iteration are as follows: Before the first iteration starts, no matching degree calibration update has been completed. Therefore, the first round of collaborative negotiation requests carries the initial matching basis feature set, initial local matching degree, initial domain adaptation feature set and initial service resource ready status data returned by each candidate vertical service domain in the aforementioned embodiments, to ensure that the input source of the first iteration is clear and unambiguous.

[0077] ③ Termination conditions and execution rules of multi-round collaborative negotiation process: In this embodiment, the multi-round collaborative negotiation process sets up dual-track mutually exclusive termination conditions. When either termination condition is met, the iteration stops immediately, and the final determination of the target vertical service domain is completed. This ensures the accuracy of intent attribution determination and avoids infinite iteration through fallback rules, thus guaranteeing the response latency of user sessions.

[0078] Termination Condition 1: Normal Convergence Termination Condition: After the iteration is completed, the target agent sorts and verifies the updated local matching degree returned by all candidate vertical service domains in this round. If there is a unique candidate vertical service domain in the set of candidate vertical service domains whose updated local matching degree is greater than the difference between the updated local matching degree of the candidate vertical service domains in the set and the difference between the updated local matching degree of the candidate vertical service domains in the set is greater than the preset difference threshold, then the iteration is determined to be converged, the iteration is stopped immediately, and the candidate vertical service domain is determined as the target vertical service domain.

[0079] In this embodiment, the verification rule for this condition is as follows: the absolute difference between the updated local matching degree of the candidate domain ranked first and the updated local matching degree of all candidate domains ranked second, third, ... Nth must be greater than a preset difference threshold in order to be deemed to meet the condition; if the difference with only some candidate domains meets the requirement, the termination condition is not triggered and the iteration continues.

[0080] Termination Condition Two: Termination due to Expiration of the Guarantee Period When the number of rounds of collaborative negotiation iteration reaches the preset maximum number of negotiation rounds, the iteration is stopped immediately regardless of whether the convergence requirement of condition one is met. The candidate vertical service domain with the highest local matching degree after the final update is selected from the candidate vertical service domain set and determined as the target vertical service domain.

[0081] In this embodiment, the preset maximum negotiation rounds range is [2,5], with a preferred value of 3 rounds. This threshold can be adaptively adjusted according to the session response latency requirements of the target service platform. For C-end user session scenarios with high real-time interaction requirements, it can be set to 2-3 rounds. For B-end service scenarios where accuracy requirements are higher than latency requirements, it can be set to 4-5 rounds. The core of setting this threshold is to balance the accuracy of intent determination with the user session waiting time, and to avoid excessive iterations that could lead to a decline in user experience.

[0082] The following will use a comprehensive lifestyle service platform as an example to illustrate the multi-round collaborative negotiation process: The target service platform comprises three vertical service domains: local life services, financial services, and travel services. The preset difference threshold is 0.1, and the preset maximum number of negotiation rounds is 3. When a user initiates a conversation with the dialogue content "Going to eat in the shopping district this weekend, looking for good deals," after the first round of parallel verification as described in the aforementioned embodiment, the initial local matching degree returned by the local life services domain is 0.89, and the initial local matching degree returned by the financial services domain (credit card dining discounts) is 0.86. The difference between the two is 0.03, which is less than the preset difference threshold of 0.1, triggering a multi-round collaborative negotiation process.

[0083] In the first iteration: the target agent distributes the initial matching criteria, initial matching degree, intra-domain adaptation features, and resource readiness status data between the two candidate domains; after receiving the matching criteria from the financial domain, the local life service domain identifies that the user has a corresponding bank credit card, supplements the preferential matching features of the bank's co-branded merchants in this domain, and calibrates the updated local matching degree to 0.93; after receiving the matching criteria from the local life domain, the financial service domain identifies that the user's core intent is in-store consumption rather than financial product application, and calibrates the updated local matching degree to 0.81.

[0084] Convergence verification: After this round of iteration, the difference in matching degree between the two candidate domains after the update is 0.12, which is greater than the preset difference threshold of 0.1. The first termination condition is met, the iteration is stopped immediately, and the local life service domain is finally determined as the target vertical service domain.

[0085] The multi-round collaborative negotiation process in this embodiment breaks down the information silos of each vertical service domain, realizes decision-making collaboration between multiple domains through multi-round information synchronization, avoids the information limitations of independent decision-making in a single domain, and improves the accuracy of intent attribution determination. On the other hand, through dual-track termination conditions, it not only ensures the accuracy of matching degree differentiation, but also completely avoids the risk of infinite iteration, ensures the real-time nature of conversation interaction, and is fully adaptable to the interaction scenario of multi-round dialogue of intelligent agents.

[0086] In some optional embodiments, step 13 in the foregoing embodiments, "based on the identity attribute reasoning model, constructing the user's identity attribute graph within the target vertical service domain according to the basic profile, target interaction data, and service intent representation," can be implemented based on the following steps: Step 131: Based on the identity attribute reasoning model, extract the user's basic attribute features from the basic profile, extract the user's historical behavior features from the target interaction data, and extract the user's real-time demand features from the service intent representation.

[0087] Among them, basic attribute features refer to the long-term, stable, and inherent characteristics of users extracted from the basic user profile. These are the basic attribute profiles that are universal across the entire platform, including but not limited to: user's age, gender, real-name authentication status, account registration duration, membership level, and usual residence region. During the feature extraction process, discrete features can be one-hot encoded, and continuous features can be normalized to output standardized basic attribute features.

[0088] Historical behavioral characteristics refer to user service domain behavioral features extracted from target interaction data within the target vertical service domain. These are the core basis for describing a user's historical preferences within that vertical service domain, including but not limited to historical browsing records, search records, favorites records, consultation records, order transaction records, virtual resource acquisition and usage records, and identity authentication records. Optionally, attenuation weights can be assigned based on the time of the behavior, assigning higher weights to recent behaviors and lower weights to older historical behaviors to highlight the user's recent behavioral preferences.

[0089] Among them, real-time demand features refer to the immediate demand features of users within the current session extracted from the service intent representation. These are the core basis for describing users' current service needs and conversion intentions, including but not limited to the user's core service demand tags, demand constraints (region, category, budget, time, etc.), urgency of the demand, the lifecycle stage of the demand, the strength of the discount offer, and explicit exclusion conditions. Optionally, corresponding fields can be extracted from the structured representation of the service intent representation to complete the standardized mapping of features, ensuring complete alignment with users' real-time demands.

[0090] Step 132: Based on basic attribute features, historical behavior features, and real-time demand features, infer the user's supply and demand identity attributes within the target vertical service domain. The supply and demand identity attributes include: service supplier attributes and service demander attributes.

[0091] Among them, the service demander attribute refers to the user identity that has the demand for service consumption, service acquisition, and resource use within the corresponding vertical service domain, and is one of the core targets of virtual resources; for example, tenants and second-hand home buyers in the real estate service domain, job seekers in the recruitment service domain, service purchasers in the housekeeping service domain, and in-store consumers in the local business service domain.

[0092] Service provider attributes refer to the user identities that provide services, publish resources, and seek cooperation within the corresponding vertical service domain. They are the core supply side of the platform's service ecosystem; for example, landlords and second-hand home sellers in the real estate service domain, corporate recruiters and HR in the recruitment service domain, service providers and merchants in the housekeeping service domain, and store merchants in the local business service domain.

[0093] Step 133: Construct an identity attribute graph with supply and demand identity attributes as the core nodes and basic attribute features, historical behavior features, and real-time demand features as related nodes.

[0094] Optionally, the identity attribute graph can be a directed attribute graph, which can adopt a three-level hierarchical structure of "core node - first-level associated node - second-level associated node", with each node and associated edge carrying quantifiable and interpretable attribute information.

[0095] In constructing the identity attribute graph, core supply and demand identity nodes are created, and node attribute values ​​are assigned. Next, three first-level related nodes are created, and their associated edges with the core nodes are created and weights are assigned. Finally, corresponding second-level feature nodes are created for each first-level related node, and feature values ​​are assigned, associated edges are created, and importance scores are assigned, ultimately generating a complete and standardized identity attribute graph. The above is merely an illustrative description of the identity attribute graph; other structures can also be used, and this embodiment does not impose limitations.

[0096] In this way, based on the identity attribute reasoning model, the identity attribute graph of a user in the target vertical service domain can be constructed relatively accurately and efficiently.

[0097] In some optional embodiments, step 14 of the aforementioned embodiment, "based on the resource adaptation metric model, constructing a relationship graph between each candidate virtual resource and user within the target vertical service domain according to the service intent representation and identity attribute graph," can be implemented based on the following steps 141-143: Step 141: Based on the resource adaptation quantification model, encode each node in the service intent representation and identity attribute graph into a high-dimensional feature vector of the user, and encode the attribute information and applicable scenario information of each candidate virtual resource into a high-dimensional feature vector of the resource.

[0098] The resource adaptation metric model can adopt a dual-tower deep neural network architecture, which includes independent user encoding towers, resource encoding towers, and a shared top-level semantic mapping layer. The model is pre-trained by comparative learning using historical user-virtual resource interaction data from each vertical service domain of the target service platform. Positive samples are virtual resource pairing data that users have claimed and successfully used, while negative samples are virtual resource pairing data that users have not claimed, claimed but not used, or have not converted. This ensures that the model has accurate semantic matching and adaptation metric capabilities.

[0099] The user encoding pyramid of the model encodes all node information in the service intent representation and identity attribute graph into a unified high-dimensional user feature vector. The first step involves end-to-end encoding of the identity attribute graph, traversing the full attribute information and edge weights of core nodes, first-level related nodes, and second-level related nodes to extract global structural features and node semantic features, outputting a fixed-dimensional global feature vector. The second step fuses the structured and vectorized representations of the service intent representation, extracting the core semantic features of the user's real-time needs, and outputting an intent feature vector with the same dimension as the global feature vector. The third step concatenates the global feature vector and the intent feature vector, performing feature cross-cutting and dimensionality compression through multiple fully connected layers to output a standardized high-dimensional user feature vector. The vector dimension is fixed, aligned with the input dimension of the model's top-level semantic mapping layer, and its value range is normalized to the [0,1] interval to eliminate differences in magnitude between different feature dimensions.

[0100] When encoding the attribute information and applicable scenario information of each candidate virtual resource into a high-dimensional feature vector, the process first involves retrieving currently active and distributable candidate virtual resources from the service nodes of the target vertical service domain, extracting the attribute information and applicable scenario information for each candidate virtual resource, and then independently encoding the information of each candidate virtual resource using a resource encoding tower to generate a high-dimensional feature vector consistent with the user's high-dimensional feature vector dimension. The basic attribute information may include: unique resource identifier, resource type (instant discount coupon, full reduction coupon, discount coupon, benefit experience coupon, etc.), discount level, usage threshold, validity period, remaining inventory, and distribution rules. The applicable scenario information describes at least one of the following: applicable vertical service domain, subdivided service scenario, applicable geographical scope, applicable supply and demand identity, applicable user tags (new / old customers, high-value users / ordinary users, etc.), disabling conditions, and blacklist / whitelist rules. During the encoding process, discrete rule-based fields can be embedded and encoded, continuous numerical fields can be normalized, and text-based scene description fields can be semantically encoded. Finally, the data is fused to generate a standardized high-dimensional feature vector for resources, ensuring that each candidate virtual resource corresponds to a high-dimensional feature vector.

[0101] Step 142: Map the user's high-dimensional feature vector and the high-dimensional feature vectors of each resource to the same high-dimensional feature vector space, and calculate the cosine similarity between the user's high-dimensional feature vector and the high-dimensional feature vectors of each resource.

[0102] Specifically, the shared top-level semantic mapping layer of the resource adaptation metric model can synchronously map user high-dimensional feature vectors and resource high-dimensional feature vectors to the same high-dimensional semantic feature space. This eliminates the semantic distribution differences between user-side and resource-side features, resolves the semantic gap problem of cross-modal features, and ensures semantic consistency in subsequent similarity calculations. During the mapping process, the semantic direction information of the feature vectors can be preserved, the absolute value differences of the feature vectors can be weakened, and the calculation characteristics of cosine similarity can be adapted to ensure that the mapped vectors can be directly used for adaptation metric.

[0103] Step 143: Determine the fit between each candidate virtual resource and the user based on cosine similarity, and construct a relationship graph based on the fit. The relationship graph is used to reflect the fit between candidate virtual resources and users. The specific implementation process is as follows: In this embodiment, the relationship graph is a directed weighted heterogeneous graph, used to quantify the multi-dimensional adaptation relationships between users and candidate virtual resources in a session scenario within a target vertical service domain. Simultaneously, it fully preserves the interpretable attribution chain of the adaptation calculation, solving the problems of current resource adaptation only outputting matching scores, lacking matching basis, and the decision-making process being a black box. The complete data structure, construction logic, and related attributes of the relationship graph will be described in detail below.

[0104] I. The nodes in the relationship graph are divided into three main categories: user entity nodes, adaptation dimension feature nodes, and virtual resource entity nodes. The identification rules and full attribute definitions for each type of node are as follows: The user subject node is the root core node of the relationship graph. There is one user subject node in a single relationship graph. The node identifier is the user's global user identifier (Universally Unique Identifier). The fixed attributes of the user subject node are divided into three categories, specifically including: (1) Basic attribute fields: user identifier, basic profile fusion identifier, target vertical service domain identifier, current session identifier, and current session round number; (2) Feature attribute fields: full feature vectors of the core nodes and related nodes in the identity attribute graph, including user supply and demand identity attribute features, basic attribute features, historical behavior features, real-time demand features, and standardized semantic feature vectors corresponding to the current session service intent representation; (3) Statistical attribute fields: total number of historical resource interactions, historical resource fulfillment rate, historical resource click conversion rate, and cumulative number of sessions in the same domain.

[0105] The adaptability dimension feature node is an intermediate layer node connecting the user subject node and the virtual resource entity node. It is used to carry the interpretable dimension splitting of adaptability calculation. Each adaptability dimension corresponds to a unique dimension feature node. The identifier of the adaptability dimension feature node is dimension code + session identifier. In this embodiment, the adaptability dimension feature node may include, but is not limited to, the following 5 types of core dimension nodes, which can be expanded according to the scenario requirements of the target vertical service domain: (1) Intent matching dimension node: corresponding to the matching feature of service intent representation and virtual resource applicable scenario; (2) Identity attribute matching dimension node: corresponding to the matching feature of user supply and demand identity attributes and virtual resource access conditions; (3) Historical behavior matching dimension node: corresponding to the matching feature of user historical interaction behavior and virtual resource historical distribution characteristics; (4) Basic attribute matching dimension node: corresponding to the matching feature of user basic attributes and virtual resource applicable population; (5) Real-time demand matching dimension node: corresponding to the matching feature of user real-time demand characteristics and virtual resource core rights. The fixed attributes of each adaptability dimension feature node include: dimension code, dimension name, user-side dimension sub-feature vector and dimension feature effective timestamp.

[0106] Virtual resource entity nodes are leaf nodes of the relationship graph; each candidate virtual resource in the distributable state within the target vertical service domain corresponds to a unique virtual resource entity node, and the identifier of the virtual resource entity node is the global resource ID of the virtual resource. The fixed attributes of the virtual resource entity node can be divided into the following four categories: (1) Basic attribute fields: resource ID, target vertical service domain ID, resource provider identifier, resource effective time interval, current inventory status of the resource, and resource distribution priority; (2) Feature attribute fields: attribute information encoding vector of virtual resource, applicable scenario information encoding vector, resource tag set, resource access condition feature vector, and resource core rights feature vector; (3) Statistical attribute fields: historical cumulative distribution times of the resource, historical average click rate of all users, historical fulfillment rate, historical average resource adaptability within the same domain, and resource distribution compliance verification status; (4) Adaptability result field: the final calculated value of the global adaptability between the virtual resource and the current user.

[0107] II. Edge Types, Weights, and Attributes of the Relationship Graph All edges in the relationship graph are directed and have a two-level structure: first-level association edges and second-level adaptation edges. The complete edge rules, weight definitions, and attribute fields are as follows: First-level association edges are used to connect user subject nodes with feature nodes of each fitness dimension. The fixed direction of the edges is [user subject node → fitness dimension feature node], which is used to represent the feature contribution of user features in the corresponding fitness dimension. The number of first-level association edges in a single relationship graph is the same as the number of fitness dimension feature nodes. The fixed attributes of each first-level associated edge include: (1) Edge identifier: User ID + Dimension code + Session identifier; (2) Edge weight value: The value range is fixed at [0,1], which is the weight coefficient of the adaptation dimension in the global adaptation calculation; The weight coefficient is obtained by adaptive learning based on the scene features of the target vertical service domain and the service intent representation of the current session through the multi-head attention mechanism layer in the resource adaptation metric model, and the sum of all weight coefficients is 1; For example, in the financial services vertical domain, the weight coefficient of the identity attribute matching dimension is higher than that of the basic attribute matching dimension, and in the local life service vertical domain, the weight coefficient of the real-time demand matching dimension is higher than that of the historical behavior matching dimension; (3) Extended attribute fields: Dimension feature name, user-side dimension sub-feature vector, feature contribution attribution value, weight update timestamp and dimension compliance verification mark.

[0108] Secondary adaptation edges are used to connect adaptation dimension feature nodes and virtual resource entity nodes. The fixed direction of the edges is [adaptation dimension feature node → virtual resource entity node], which is used to represent the dimension matching degree between the current user and the virtual resource under the corresponding adaptation dimension. The number of secondary adaptation edges in a single relationship graph is the number of adaptation dimension feature nodes × the total number of candidate virtual resources. The fixed attributes of each secondary adaptation edge include: (1) Edge identifier: dimension code + resource ID + session identifier; (2) Edge weight value: the value range is fixed at [0,1], which is the cosine similarity calculation value between the user-side dimension sub-feature vector and the corresponding resource-side dimension sub-feature vector under the adaptation dimension, that is, the user-resource dimension matching degree score under the dimension; (3) Extended attribute fields: dimension matching name, user-side dimension sub-feature vector, resource-side dimension sub-feature vector, original value of cosine similarity calculation, matching basis keyword set, matching anomaly mark and dimension compliance verification mark.

[0109] III. Overall Topology and Complete Construction Process of the Relationship Graph: In this embodiment, the relationship graph adopts a three-layer star topology structure of "single root core node - multi-dimensional intermediate nodes - multi-resource leaf nodes," where: the first layer is the user entity node (root node), the second layer is multiple adaptation dimension feature nodes (intermediate nodes), and the third layer is multiple virtual resource entity nodes (leaf nodes); the first and second layers are connected by first-level association edges, and the second and third layers are connected by second-level adaptation edges. There are no cross-layer edges or edges between nodes at the same layer, ensuring the standardization of the graph structure and the traceability of the adaptation calculation link. The complete construction process of the relationship graph is as follows: Step T1: Based on the resource adaptation quantification model, perform multi-node feature encoding operations, specifically including: a) concatenating the features of the service intent representation of the current session and all nodes (core supply and demand identity attribute nodes + basic attributes, historical behavior, and real-time demand related nodes) in the identity attribute graph, performing a non-linear transformation through a fully connected layer, and encoding them into a fixed-dimensional user high-dimensional feature vector. In this embodiment, the dimension of the user high-dimensional feature vector can be fixed at 1024 dimensions, and the vector dimension can be adaptively adjusted according to the scenario requirements of the target vertical service domain. b) splitting the user high-dimensional feature vector according to the preset adaptation dimension, extracting the user-side dimension sub-feature vectors corresponding to each dimension, and completing the initialization and feature assignment of each adaptation dimension feature node. c) Obtain all candidate virtual resources in the target vertical service domain that are in a distributable state and have passed compliance verification. Concatenate the attribute information, applicable scenario information, tag set, admission conditions, and core rights information of each candidate virtual resource. Perform non-linear transformation through a fully connected layer with the same structure as the user's encoding to encode it into a resource high-dimensional feature vector with the same dimension as the user's high-dimensional feature vector. Then, split it according to the adaptability dimension to obtain the resource-side dimension sub-feature vectors corresponding to each dimension, and complete the initialization and feature assignment of each virtual resource entity node.

[0110] Step T2: For each feature node of the adaptation dimension that has been initialized, construct a first-level association edge pointing from the user subject node to that dimension node. Specifically, this includes: inputting the user's high-dimensional feature vector and the service intent representation of the current session into the multi-head attention mechanism layer of the resource adaptation measurement model, calculating the attention weight of each adaptation dimension corresponding to the current service intent, and using this attention weight as the edge weight value of the corresponding first-level association edge; at the same time, writing information such as the user-side dimension sub-feature vector and feature contribution attribution value into the extended attribute field of the edge, thus completing the construction of all first-level association edges.

[0111] Step T3: For each feature node of the adaptation dimension and each virtual resource entity node, construct a secondary adaptation edge pointing from the node of that dimension to the corresponding resource node. Specifically, this includes: mapping the sub-feature vector of the user side of that dimension and the sub-feature vector of the corresponding dimension of the resource side to the same high-dimensional feature subspace, and calculating the cosine similarity between the two vectors; using the calculated cosine similarity value as the edge weight value of the secondary adaptation edge, and writing the matching criteria keyword set, the original value of the vector, and other information into the extended attribute field of the edge, thus completing the construction of all secondary adaptation edges.

[0112] Step T4: For each virtual resource entity node, calculate the global fit between the virtual resource and the current user by weighted summation based on the edge weights of all secondary adaptation edges and the edge weights of the corresponding primary related edges; write the calculated global fit into the fit result field of the corresponding virtual resource entity node, and finally generate a complete, traceable and interpretable user-virtual resource relationship graph.

[0113] Furthermore, in this embodiment, the relationship graph supports interpretable attribution output of the fit results. Specifically, for a target virtual resource whose global fit meets preset conditions, the core fit dimension with the highest matching degree is located by tracing the weight values ​​of all secondary fit edges corresponding to the virtual resource. Then, the core contribution features on the user side are located through the feature contribution attribution values ​​of the corresponding primary related edges, ultimately generating a standardized fit attribution description. For example, for a local life service virtual resource with a fit of 92%, the attribution description can be generated as follows: "This resource has a 92% fit with you. The core matching dimensions are real-time demand matching (dimension matching 95%) and service intent matching (dimension matching 93%). The matching basis is that your current in-store consumption service needs are highly consistent with the core preferential benefits and applicable store range of this resource." This achieves full-link interpretability of resource fit decisions and improves user acceptance of virtual resource distribution results.

[0114] In this way, based on the resource adaptation metric model, and according to the service intent representation and identity attribute graph, a relationship graph between each candidate virtual resource and user in the target vertical service domain can be constructed relatively efficiently and accurately.

[0115] In some optional embodiments, step 15 in the aforementioned embodiments, "selecting at least one target virtual resource that meets the fit criteria from among the candidate virtual resources based on the fitness reflected in the relationship graph," is specifically implemented through steps 151 to 153. This embodiment, based on the core of semantic fitness matching, introduces the law of diminishing marginal efficiency in virtual resource distribution. It quantifies the actual effectiveness of virtual resource distribution on system operation and user interaction through historical user interaction data. This solves the technical problems of redundant resource distribution, ineffective consumption of system computing / transmission / storage resources, and increased user session interruption rates caused by unnecessary interactions resulting from static fitness screening in traditional methods. While ensuring the accuracy of resource matching, it maximizes the balance between system resource scheduling efficiency and user interaction experience.

[0116] Step 151: For any candidate virtual resource, obtain the historical reception frequency and historical conversion data of the user for the same type of virtual resource in the target vertical service domain within a preset historical time window.

[0117] The preset historical time window is a dynamically configurable backtracking period, which is set differently according to the service conversion cycle of the target vertical service domain. For example, it can be 30-60 days for long-cycle business scenarios (such as real estate rental and second-hand housing transactions), and 7-15 days for short-cycle, high-frequency business scenarios (such as housekeeping services and local life consumption). The start and end times of the time window are the complete natural cycle of backtracking from the time the current session was initiated, ensuring the timeliness and representativeness of the data.

[0118] Historical reception frequency refers to the frequency of user interactions with similar virtual resources across the entire chain within a preset historical time window, including the number of times the platform passively pushes resources, the number of times users actively claim resources, and the number of times resources are successfully claimed. Optionally, when acquiring data, a higher statistical weight is assigned to active claiming behavior, and a basic weight is assigned to passive push behavior, in order to accurately reflect the degree of user contact with similar resources.

[0119] Historical conversion data refers to the conversion effect data of users for the same type of virtual resources within a preset historical time window, including but not limited to redemption rate, redemption order conversion rate, increase in average order value, repurchase conversion effect, marketing push cancellation rate, and complaint and report records. In other words, historical conversion data can include both positive conversion revenue data and negative user feedback data.

[0120] Step 152: Based on the pre-trained utility decay curve model, calculate the marginal utility value of the user for the current candidate virtual resource according to the historical reception frequency and historical conversion data.

[0121] Step 153: If the marginal utility value is greater than the preset minimum utility threshold and the fit of the candidate virtual resource meets the fit condition, the candidate virtual resource is determined as the target virtual resource.

[0122] The utility decay curve model can be a nonlinear regression model based on the law of diminishing marginal utility. It can be implemented using XGBoost (eXtreme Gradient Boosting), a lightweight gradient booster, or an LSTM (Long Short-Term Memory) time-series model, adaptable to the utility decay laws of different service scenarios. Optionally, the training samples for the utility decay curve model can be the full historical virtual resource distribution data of each vertical service domain of the target service platform, with the training label being the actual efficiency value of a single distribution. For example, the label calculation formula can be: in, to The weighting coefficients for the corresponding dimensions can be dynamically adjusted according to the operational goals of the target service platform. The positive benefit dimension (improved service interaction completion rate) represents the increased service link completion rate and user lifetime value resulting from effective resource utilization. The negative loss dimension (negative impact of user interaction) represents the system computation / transmission / storage resource overhead caused by virtual resource distribution actions and the decreased user experience due to interrupted / unsubscribed sessions. The utility decay curve model, through supervised learning, fits the non-linear decay relationship between the frequency of user reception of the same type of virtual resources, historical interaction behavior, and distribution efficiency.

[0123] The utility decay curve model can calculate the marginal utility value of a user for the current candidate virtual resource based on historical reception frequency and historical conversion data in the following way: Standardized preprocessing is performed on historical reception frequency and historical resource conversion data to obtain standardized input data. Weighted frequency features, resource conversion efficiency features, and user interaction feedback features are extracted from the standardized input data. Based on the weighted frequency features, a basic attenuation coefficient is calculated using a nonlinear attenuation function pre-trained in the corresponding vertical service domain. Based on the resource conversion efficiency features and user interaction feedback features, a user-specific sensitivity coefficient is calculated. Based on the fit between the current candidate virtual resource and the user, and the degree of differentiation between the current candidate virtual resource and historical virtual resources of the same type, a scenario-based correction coefficient is calculated. Based on the basic attenuation coefficient, the personalized sensitivity coefficient, and the scenario-based correction coefficient, the marginal efficiency value of the user for the current candidate virtual resource is calculated. Candidate virtual resources with a marginal efficiency value greater than a preset minimum efficiency threshold and a fit that meets preset fit conditions are selected as target virtual resources.

[0124] In this way, based on the core of semantic fit matching, the law of diminishing marginal efficiency of virtual resource distribution is introduced. By quantifying the actual efficiency of virtual resource distribution on system operation and user interaction through user historical interaction data, this method solves the technical problems of redundant resource distribution, ineffective consumption of system computing / transmission / storage resources, and increased user session interruption rate caused by unnecessary interactions, which are caused by static fit matching in traditional methods. This method maximizes the balance between system resource scheduling efficiency and user interaction experience while ensuring the accuracy of resource matching.

[0125] In some optional embodiments, before selecting at least one target virtual resource that meets the suitability criteria from among the candidate virtual resources based on the suitability reflected in the relationship graph, runtime context metadata of the user's terminal device can also be collected. Runtime context metadata includes at least one of application version information, system version information, network status information, and geographic location information. Specifically, runtime context metadata refers to non-privacy basic data reported in real-time by the terminal device when the user initiates a session, used to characterize the device and environment status; application version information refers to the current version number of the target service platform client; system version information refers to the type and version of the terminal device's operating system; network status information refers to the current network connection method and network quality; and geographic location information refers to the user's authorized real-time location area. Based on the runtime context metadata, environmental suitability verification is performed on each candidate virtual resource, and candidate virtual resources that fail the environmental suitability verification are eliminated. Environmental suitability verification verifies whether the processes for obtaining, displaying, and using candidate virtual resources are compatible with the current device environment, version requirements, and regional restrictions, and candidate virtual resources that fail the environmental suitability verification are eliminated to avoid resource distribution failures, abnormal interactions, or regional violations due to environmental incompatibility.

[0126] In some optional embodiments, after the step of distributing at least one target virtual resource to the user's terminal device, subsequent interaction data of the user on the target virtual resource can also be obtained. The subsequent interaction data includes at least one of viewing data, usage data, and conversion data. Based on the subsequent interaction data and the dialogue content in the multi-turn dialogue process, the user's basic profile is updated. The resource adaptation metric model is incrementally fine-tuned and optimized using the service intent representation as input and the conversion results corresponding to the subsequent interaction data as supervision labels.

[0127] It should be noted that the execution subject of each step of the method provided in the above embodiments can be the same device, or the method can be executed by different devices. For example, the execution subject of steps 11 to 15 can be device A; or the execution subject of steps 11 to 12 can be device A, and the execution subject of steps 13 to 15 can be device B; and so on.

[0128] Furthermore, some processes described in the above embodiments and accompanying drawings include multiple operations that appear in a specific order. However, it should be clearly understood that these operations may not be executed in the order they appear herein, or they may be executed in parallel. The operation numbers, such as 12, 13, etc., are merely used to distinguish different operations and do not represent any execution order. In addition, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel.

[0129] It should be noted that the terms "first" and "second" in this article are used to distinguish different messages, devices, modules, etc., and do not represent a chronological order, nor do they limit "first" and "second" to different types.

[0130] Figure 2 This is a schematic diagram of the structure of an electronic device provided in an exemplary embodiment of this application. This electronic device is applicable to the virtual resource allocation method provided in the foregoing embodiments, and is applied to a target intelligent agent deployed in a target service platform. The target intelligent agent communicates and interfaces with service nodes of multiple vertical service domains in the target service platform. Figure 2 As shown, the electronic device may include: a memory 201, a processor 202, and a communication component 203.

[0131] Memory 201 is used to store computer programs and can be configured to store various other data to support operation on the electronic device. Examples of this data include instructions for any application or method used to operate on the electronic device, contact data, phone book data, messages, pictures, videos, etc.

[0132] In some exemplary embodiments, processor 202, coupled to memory 201, is configured to execute a computer program in memory 201 for: responding to a user-initiated session and obtaining a basic profile of the user; wherein the basic profile is obtained by fusing the user's attribute data, spatiotemporal data, and historical interaction data; during multi-turn dialogues with the user, obtaining the target dialogue content input by the user in the current turn, and identifying the user's service intent representation from the target dialogue content based on a large language model associated with the target agent; determining the target vertical service domain to which the service intent belongs based on the service intent representation and in collaboration with service nodes in each vertical service domain; and identifying the target vertical service domain from the service nodes corresponding to the target vertical service domain. The system acquires the user's target interaction data within the target vertical service domain; based on an identity attribute reasoning model, it constructs the user's identity attribute graph within the target vertical service domain according to the basic profile, the target interaction data, and the service intent representation; based on a resource adaptation quantification model, it constructs a relationship graph between each candidate virtual resource within the target vertical service domain and the user according to the service intent representation and the identity attribute graph, the relationship graph reflecting the fit between the candidate virtual resources and the user; based on the fit reflected in the relationship graph, it selects at least one target virtual resource that meets the fit condition from the candidate virtual resources and distributes the at least one target virtual resource to the user's terminal device.

[0133] Optionally, when the processor 202 determines the target vertical service domain to which the service intent belongs based on the service intent representation and the service nodes on each vertical service domain, it is specifically configured to: extract features from the service intent representation based on the large language model to obtain a standardized semantic feature vector, and generate an intent verification request carrying the standardized semantic feature vector and the user's identifier; distribute the intent verification request in parallel to the service nodes corresponding to each vertical service domain; receive the domain matching response returned by each service node for the intent verification request, wherein the domain matching response returned by any service node includes: the local matching degree between the vertical service domain corresponding to the service node and the service intent representation and the matching basis feature set, wherein the local matching degree is calculated by the service node based on the locally deployed domain intent matching model and local rule base; determine a set of candidate vertical service domains whose local matching degree meets the preset conditions based on the domain matching response returned by each service node; if there is only one candidate vertical service domain in the set of candidate vertical service domains, then determine the candidate vertical service domain as the target vertical service domain.

[0134] Optionally, the processor 202 is further configured to: initiate a multi-round collaborative negotiation process when at least two candidate vertical service domains in the candidate vertical service domain set have a local matching degree difference less than a preset difference threshold; in each iteration of the multi-round collaborative negotiation process, distribute a collaborative negotiation request to the service node corresponding to each candidate vertical service domain, the collaborative negotiation request carrying the matching basis feature set, updated local matching degree, domain adaptation feature set, and service resource readiness status data of the remaining candidate vertical service domains; and receive the service node of each candidate vertical service domain recalculated and returned based on the collaborative negotiation request. The updated local matching degree and matching basis feature set; the multi-round collaborative negotiation process stops iteration when any of the following termination conditions are met: Condition 1: In the candidate vertical service domain set after iteration, there is a unique candidate vertical service domain whose updated local matching degree is greater than the preset difference threshold with the updated local matching degree of all other candidate vertical service domains in the set, and the candidate vertical service domain is determined as the target vertical service domain; Condition 2: The iteration round reaches the preset maximum negotiation round, and the candidate vertical service domain with the highest updated local matching degree is selected from the candidate vertical service domain set and determined as the target vertical service domain.

[0135] Optionally, when the processor 202 constructs the user's identity attribute graph within the target vertical service domain based on the identity attribute reasoning model, according to the basic profile, the target interaction data, and the service intent representation, it specifically performs the following: based on the identity attribute reasoning model, it extracts the user's basic attribute features from the basic profile, the user's historical behavior features from the target interaction data, and the user's real-time demand features from the service intent representation; based on the basic attribute features, the historical behavior features, and the real-time demand features, it infers the user's supply and demand identity attributes within the target vertical service domain, wherein the supply and demand identity attributes include: service supplier attributes and service demander attributes; and constructs the identity attribute graph with the supply and demand identity attributes as the core node and the basic attribute features, historical behavior features, and real-time demand features as related nodes.

[0136] Optionally, when the processor 202 constructs the relationship graph between each candidate virtual resource and the user within the target vertical service domain based on the resource adaptation metric model, according to the service intent representation and the identity attribute graph, it specifically performs the following steps: based on the resource adaptation metric model, it encodes each node in the service intent representation and the identity attribute graph into a high-dimensional user feature vector, and encodes the attribute information and applicable scenario information of each candidate virtual resource into a high-dimensional resource feature vector; it maps the high-dimensional user feature vector and each high-dimensional resource feature vector to the same high-dimensional feature vector space, and calculates the cosine similarity between the high-dimensional user feature vector and each high-dimensional resource feature vector; it determines the adaptation degree between each candidate virtual resource and the user based on the cosine similarity, and constructs the relationship graph based on the adaptation degree.

[0137] Optionally, when the processor 202 selects at least one target virtual resource that meets the fit criteria from the candidate virtual resources based on the fit criteria reflected in the relationship graph, it specifically performs the following steps: for any candidate virtual resource, it acquires the historical reception frequency and historical conversion data of the user for the same type of virtual resource in the target vertical service domain within a preset historical time window; based on a pre-trained utility decay curve model, it calculates the marginal utility value of the user for the current candidate virtual resource according to the historical reception frequency and historical conversion data; and when the marginal utility value is greater than a preset minimum efficiency threshold and the fit criteria of the candidate virtual resource meet the fit criteria, it determines the candidate virtual resource as the target virtual resource.

[0138] Optionally, before the processor 202 selects at least one target virtual resource that meets the adaptation criteria from the candidate virtual resources based on the adaptation degree reflected in the relationship graph, it is further configured to: collect runtime context metadata of the user's terminal device, wherein the runtime context metadata includes at least one of application version information, system version information, network status information, and geographical location information; and perform environmental adaptability verification on each candidate virtual resource based on the runtime context metadata, and eliminate candidate virtual resources that fail the environmental adaptability verification.

[0139] This application also provides a computer-readable storage medium that, when executed by a processor, enables the processor to implement the steps in the virtual resource allocation method.

[0140] This application also provides a computer program product, including a computer program / instruction, which, when executed by a processor, enables the processor to implement the steps in the virtual resource allocation method.

[0141] In this embodiment, a basic user profile is obtained, and service intent representations are identified from user dialogue content using a large language model. Collaboration with service nodes in various vertical service domains determines the target vertical service domain to which the service intent belongs, and target interaction data of the user within that domain is obtained. Based on an identity attribute reasoning model, an identity attribute graph of the user within the target vertical service domain is constructed according to the basic profile, target interaction data, and service intent representations. This graph, combined with the service intent representations, generates a relationship graph reflecting the suitability between resources and users. Target virtual resources are then selected and distributed based on this relationship graph. This approach achieves multi-domain collaborative negotiation and decision-making regarding service intent attribution, breaking the limitations of unilateral decision-making at the central end, reducing the misjudgment rate of intent attribution, realizing dynamic and accurate matching of virtual resources with user needs, and improving resource distribution efficiency.

[0142] Furthermore, such as Figure 2 As shown, the electronic device also includes other components such as a display 204, a power supply component 205, and an audio component 206. Figure 2 The diagram only shows some components and does not mean that the electronic device includes only these components. Figure 2 The components shown.

[0143] The aforementioned memory can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random-Access Memory (SRAM), Electrically Erasable Programmable Read Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0144] The aforementioned communication components are configured to facilitate wired or wireless communication between the device containing the communication components and other devices. The device containing the communication components can access wireless networks based on communication standards, such as WiFi, 2G, 3G, 4G / LTE, 5G, or combinations thereof. In one exemplary embodiment, the communication components receive broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, the communication components also include a Near Field Communication (NFC) module to facilitate short-range communication. For example, the NFC module may be implemented based on Radio Frequency Identification (RFID), Infrared Data Association (IrDA), Ultra Wide Band (UWB), Bluetooth (BT), and other technologies.

[0145] The aforementioned display includes a screen, which may include a Liquid Crystal Display (LCD) and a Touch Panel (TP). If the screen includes a Touch Panel, the screen can be implemented as a touchscreen to receive input signals from the user. The Touch Panel includes one or more touch sensors to sense touches, swipes, and gestures on the Touch Panel. The touch sensors can sense not only the boundaries of touch or swipe actions but also the duration and pressure associated with the touch or swipe operation.

[0146] The aforementioned power supply components provide power to various components within the device in which they reside. These power supply components may include a power management system, one or more power sources, and other components associated with generating, managing, and distributing power to the device in which they reside.

[0147] The aforementioned audio component can be configured to output and / or input audio signals. For example, the audio component includes a microphone (MIC) configured to receive external audio signals when the device containing the audio component is in an operating mode, such as call mode, recording mode, or voice recognition mode. The received audio signals can be further stored in memory or transmitted via a communication component. In some embodiments, the audio component also includes a speaker for outputting audio signals.

[0148] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-readable storage media (including, but not limited to, disk storage, compact disc read-only memory (CD-ROM), optical storage, etc.) containing computer-usable program code.

[0149] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0150] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0151] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0152] In a typical configuration, a computing device includes one or more processors (Central Processing Unit, CPU), input / output interfaces, network interfaces, and memory.

[0153] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0154] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change random access memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, Digital Video Disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0155] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0156] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method for allocating virtual resources, characterized in that, A method for applying a target intelligent agent deployed in a target service platform, wherein the target intelligent agent communicates and interfaces with service nodes of multiple vertical service domains in the target service platform, the method comprising: In response to a user initiating a session, the system obtains the user's basic profile; wherein, the basic profile is obtained by fusing the user's attribute data, spatiotemporal data, and historical interaction data; During the multi-round dialogue with the user, the target dialogue content input by the user in the current round is obtained, and the service intent representation of the user is identified from the target dialogue content based on the large language model associated with the target agent. The target vertical service domain to which the service intent belongs is determined in collaboration with the service nodes on each vertical service domain based on the service intent representation, and the target interaction data of the user in the target vertical service domain is obtained from the service node corresponding to the target vertical service domain. Based on the identity attribute reasoning model, the user's identity attribute graph within the target vertical service domain is constructed according to the basic profile, the target interaction data, and the service intent representation. Based on the resource adaptation quantification model, a relationship graph between each candidate virtual resource in the target vertical service domain and the user is constructed according to the service intent representation and the identity attribute graph. The relationship graph is used to reflect the adaptation degree between the candidate virtual resources and the user. Based on the fit degree reflected in the relationship graph, at least one target virtual resource that meets the fit degree condition is selected from the candidate virtual resources, and the at least one target virtual resource is distributed to the user's terminal device.

2. The method according to claim 1, characterized in that, Based on the service intent representation and in collaboration with service nodes in each vertical service domain, the target vertical service domain to which the service intent belongs is determined, including: Based on the large language model, feature extraction is performed on the service intent representation to obtain a standardized semantic feature vector, and an intent verification request carrying the standardized semantic feature vector and the user's user identifier is generated. The intent verification request is then distributed in parallel to the service nodes corresponding to each vertical service domain. The system receives intra-domain matching responses returned by each of the service nodes in response to the intent verification request. The intra-domain matching response returned by any service node includes: the local matching degree between the vertical service domain corresponding to the service node and the service intent representation and the matching basis feature set. The local matching degree is calculated by the service node based on the locally deployed intra-domain intent matching model and local rule base. Based on the intra-domain matching response returned by each service node, a set of candidate vertical service domains whose local matching degree meets the preset conditions is determined. If there is only one candidate vertical service domain in the set of candidate vertical service domains, the candidate vertical service domain is determined as the target vertical service domain.

3. The method according to claim 2, characterized in that, Also includes: If at least two candidate vertical service domains in the candidate vertical service domain set have a local matching degree difference less than a preset difference threshold, a multi-round collaborative negotiation process is initiated. In each iteration of the multi-round collaborative negotiation process, a collaborative negotiation request is distributed to the service node corresponding to each candidate vertical service domain. The collaborative negotiation request carries the matching basis feature set, the updated local matching degree, the domain adaptation feature set and service resource readiness status data of the other candidate vertical service domains; and the updated local matching degree and matching basis feature set recalculated and returned by the service node of each candidate vertical service domain based on the collaborative negotiation request are received. The multi-round collaborative negotiation process stops iterating when any of the following termination conditions are met: Condition 1: In the set of candidate vertical service domains after iteration, there exists a unique candidate vertical service domain whose updated local matching degree differs from the updated local matching degrees of all other candidate vertical service domains in the set by more than the preset difference threshold. In this case, the candidate vertical service domain is determined as the target vertical service domain. Condition 2: When the number of iterations reaches the preset maximum negotiation round, the candidate vertical service domain with the highest local matching degree after the update is selected from the candidate vertical service domain set and determined as the target vertical service domain.

4. The method according to claim 1, characterized in that, Based on the identity attribute reasoning model, and according to the basic profile, the target interaction data, and the service intent representation, an identity attribute graph of the user within the target vertical service domain is constructed, including: Based on the identity attribute reasoning model, the user's basic attribute features are extracted from the basic profile, the user's historical behavior features are extracted from the target interaction data, and the user's real-time demand features are extracted from the service intent representation. Based on the basic attribute features, the historical behavior features, and the real-time demand features, the supply and demand identity attributes of the user in the target vertical service domain are inferred. The supply and demand identity attributes include: service supplier attributes and service demander attributes. Using the supply and demand identity attributes as the core nodes, and the basic attribute features, historical behavior features, and real-time demand features as related nodes, the identity attribute graph is constructed.

5. The method according to claim 1, characterized in that, Based on the resource adaptation quantification model, and according to the service intent representation and the identity attribute graph, a relationship graph between each candidate virtual resource and the user within the target vertical service domain is constructed, including: Based on the resource adaptation quantification model, the service intent representation and each node in the identity attribute graph are encoded into user high-dimensional feature vectors, and the attribute information and applicable scenario information of each candidate virtual resource are encoded into resource high-dimensional feature vectors. Map the user's high-dimensional feature vector and each resource's high-dimensional feature vector to the same high-dimensional feature vector space, and calculate the cosine similarity between the user's high-dimensional feature vector and each resource's high-dimensional feature vector. The compatibility between each candidate virtual resource and the user is determined based on the cosine similarity, and the relationship graph is constructed based on the compatibility.

6. The method according to claim 1, characterized in that, Based on the fit degree reflected in the relationship graph, at least one target virtual resource that meets the fit degree condition is selected from the candidate virtual resources, including: For any candidate virtual resource, obtain the historical reception frequency and historical conversion data of the user for the same type of virtual resource in the target vertical service domain within a preset historical time window; Based on a pre-trained utility decay curve model, the marginal utility value of the user for the current candidate virtual resource is calculated according to the historical reception frequency and historical conversion data. If the marginal utility value is greater than a preset minimum efficiency threshold and the fit of the candidate virtual resource meets the fit condition, the candidate virtual resource is determined as the target virtual resource.

7. The method according to claim 1, characterized in that, Before selecting at least one target virtual resource that meets the fit criteria from the candidate virtual resources based on the fitness reflected in the relationship graph, the process further includes: The runtime context metadata of the user's terminal device is collected, and the runtime context metadata includes at least one of application version information, system version information, network status information, and geographical location information; Based on the runtime context metadata, each candidate virtual resource is subjected to environment compatibility verification, and candidate virtual resources that fail the environment compatibility verification are eliminated.

8. An electronic device, characterized in that, include: A memory and a processor; wherein the memory is configured to: store one or more computer instructions; and the processor is configured to execute the one or more computer instructions to: perform the steps of the method according to any one of claims 1-7.

9. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it causes the processor to perform the steps of the method according to any one of claims 1-7.

10. A computer program product, characterized in that, Includes a computer program / instruction that, when executed by a processor, causes the processor to perform the steps of the method according to any one of claims 1-7.

Images