Dialogue request processing methods, apparatus, equipment, media, and program products

Abstract

This application relates to a method, apparatus, device, medium, and program product for processing dialogue requests. It includes: for a received dialogue request, identifying the business semantic key and business intent included in the dialogue request; constructing a dialogue call chain matrix and a request cancellation token corresponding to the dialogue call chain matrix; generating a cross-layer scheduling instruction set based on the dialogue call chain matrix; retaining non-cancelled and non-duplicate sub-dialogue requests in the dialogue request based on a request cancellation mapping table and cross-layer deduplication keys in the cross-layer scheduling instruction set, and marking them as a set of valid sub-dialogue requests; asynchronously delivering the set of valid sub-dialogue requests to an edge-side queue and a cloud-side queue based on the cross-layer scheduling instruction set; and performing cross-layer parallel processing on the sub-dialogue requests in the set of valid sub-dialogue requests based on the edge-side queue and the cloud-side queue. This method can avoid the situation where a sub-dialogue request is repeatedly executed on the cloud side and the edge side, reducing load and improving processing efficiency.

Description

Technical Field

[0001] This application relates to the field of request processing technology, and in particular to a method, apparatus, device, medium, and program product for processing dialogue requests. Background Technology

[0002] Electric vehicle charging service platforms serve a massive number of users, experiencing a surge in requests during peak hours. To reduce network latency and alleviate pressure on cloud centers, the industry commonly deploys edge nodes at the city or station level to handle local caching and preprocessing tasks. With the increase in conversational interactions, large-scale parallel calls and result feedback occur between the edge and cloud centers.

[0003] In the charging service platform, to generate a complete answer for a user's dialogue request, the dialogue orchestration module may trigger queries from multiple tool services simultaneously or sequentially. For each tool service, different sub-dialogue requests will be generated. These sub-dialogue requests may have sequential dependencies, and their return times may differ significantly. When a dialogue times out or is answered prematurely, unnecessary sub-dialogue requests may continue to consume resources, and retries triggered by timeouts may further amplify the concurrency pressure.

[0004] Therefore, existing technologies may result in unnecessary sub-dialogue requests continuing to consume resources, and may also amplify concurrency pressure by triggering retries due to timeouts. Summary of the Invention

[0005] Therefore, it is necessary to provide a method, apparatus, computer device, computer-readable storage medium, and computer program product that can address the above-mentioned technical problems by resolving the issue of unnecessary sub-dialogue requests continuing to occupy resources.

[0006] Firstly, this application provides a method for processing dialogue requests, including:

[0007] For a received dialogue request, identify the business semantic key and business intent included in the dialogue request, construct a dialogue call chain matrix and a request cancellation token corresponding to the dialogue call chain matrix; the dialogue request contains at least one sub-dialogue request, and each dialogue request corresponds to a unique request cancellation token;

[0008] Based on the dialogue call chain matrix, time window shaping and semantic merging are performed on the sub-dialogue requests of each dialogue request to generate an edge merging request set, and a correspondence is established between the request cancellation token and the edge merging request set to form a request cancellation mapping table;

[0009] Based on the business semantic keys and business intents in the edge merging request set, a cross-layer scheduling instruction set is generated; the cross-layer scheduling instruction set includes a cross-layer deduplication key; each cross-layer deduplication key corresponds to a business type;

[0010] Based on the request cancellation mapping table and the cross-layer deduplication key in the cross-layer scheduling instruction set, retain the non-cancelled and non-duplicate sub-dialogue requests in the dialogue request and mark them as a valid set of sub-dialogue requests.

[0011] Based on the cross-layer scheduling instruction set, the effective sub-dialogue request set is asynchronously delivered to the edge-side queue and the cloud-side queue, and the sub-dialogue requests in the effective sub-dialogue request set are processed in parallel across layers based on the edge-side queue and the cloud-side queue.

[0012] Secondly, this application also provides a processing apparatus for dialogue requests, comprising:

[0013] The identification building module is used to identify the business semantic key and business intent included in the received dialogue request, construct a dialogue call chain matrix and a request cancellation token corresponding to the dialogue call chain matrix; the dialogue request contains at least one sub-dialogue request, and each dialogue request corresponds to a unique request cancellation token;

[0014] The generation module is used to perform time window shaping and semantic merging for each dialogue request's sub-dialogue requests based on the dialogue call chain matrix, generate an edge merging request set, and establish a correspondence between the request cancellation token and the edge merging request set to form a request cancellation mapping table.

[0015] The generation module is used to generate a cross-layer scheduling instruction set based on the business semantic keys and business intents in the edge merging request set; wherein, the cross-layer scheduling instruction set includes a cross-layer deduplication key; each cross-layer deduplication key corresponds to a business type;

[0016] The retention tag module is used to retain non-cancelled and non-duplicate sub-dialogue requests in the dialogue request based on the request cancellation mapping table and the cross-layer deduplication key in the cross-layer scheduling instruction set, and to mark them as a set of valid sub-dialogue requests.

[0017] The cross-layer parallel module is used to asynchronously deliver the effective sub-dialogue request set to the edge-side queue and the cloud-side queue based on the cross-layer scheduling instruction set, and to perform cross-layer parallel processing on the sub-dialogue requests in the effective sub-dialogue request set based on the edge-side queue and the cloud-side queue.

[0018] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the method described above.

[0019] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described above.

[0020] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the method described above.

[0021] The aforementioned method, apparatus, computer equipment, computer-readable storage medium, and computer program product for processing dialogue requests are applied to a dialogue request processing system, which includes cloud-side and edge-side components. For a received dialogue request, the system identifies the business semantic key and business intent included in the dialogue request, constructs a dialogue call chain matrix and a request cancellation token corresponding to the dialogue call chain matrix, and recognizes that each dialogue request contains at least one sub-dialogue request, with each dialogue request corresponding to a unique request cancellation token. Based on the dialogue call chain matrix, the system performs time window shaping and semantic merging on the sub-dialogue requests of each dialogue request, generates an edge-merged request set, and associates the request cancellation token with the edge... The process involves merging request sets to establish a corresponding relationship, forming a request cancellation mapping table. Based on the business semantic keys and business intents in the merged request sets at the edge, a cross-layer scheduling instruction set is generated. This cross-layer scheduling instruction set includes a cross-layer deduplication key; each cross-layer deduplication key corresponds to a business type. Based on the request cancellation mapping table and the cross-layer deduplication keys in the cross-layer scheduling instruction set, non-cancelled and non-duplicate sub-dialogue requests are retained and marked as valid sub-dialogue request sets. Based on the cross-layer scheduling instruction set, the valid sub-dialogue request sets are asynchronously delivered to the edge-side queue and the cloud-side queue. The sub-dialogue requests in the valid sub-dialogue request sets are then processed in parallel across layers based on the edge-side queue and the cloud-side queue. By constructing a dialogue call chain matrix and a request cancellation token using the business semantic keys and business intents of the dialogue requests, semantic merging is performed according to the dialogue call chains. This enables the merging of semantically identical sub-dialogue requests, avoiding multiple processing of the same query and reducing unnecessary load. A request cancellation token is mapped to the edge merge request set to form a request cancellation mapping table. This allows for accurate identification of semantically duplicated sub-dialogue requests using the request cancellation token. Then, the business semantic keys and business intents in the edge merge request set are used to generate a cross-layer scheduling instruction set. This cross-layer instruction scheduling set can promptly terminate invalid sub-dialogue requests, preventing them from continuing to execute on the edge or cloud side, consuming valuable resources and increasing concurrency pressure. Next, based on the request cancellation mapping table and the cross-layer deduplication key in the cross-layer scheduling instruction set, non-cancelled and non-duplicate sub-dialogue requests are retained and marked as valid sub-dialogue request sets. These valid sub-dialogue request sets prevent invalid or already executed dialogue requests from continuing to execute, effectively achieving cross-layer deduplication and merging. Through the synergistic effect of the dialogue call chain matrix, request cancellation mapping table, cross-layer scheduling instruction set, and valid sub-dialogue request set, sub-dialogue requests can be thoroughly deduplicated, invalid sub-dialogue requests can be promptly removed, and the situation of a sub-dialogue request being repeatedly executed on both the cloud and edge sides can be avoided, reducing load and improving processing efficiency. Attached Figure Description

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

[0023] Figure 1 This is an application environment diagram of a dialog request processing method in one embodiment;

[0024] Figure 2 This is a flowchart illustrating a method for processing dialogue requests in one embodiment;

[0025] Figure 3 This is a schematic diagram illustrating the process of constructing a dialogue call chain and requesting a cancellation token in one embodiment;

[0026] Figure 4 This is a structural block diagram of a dialog request processing device in one embodiment;

[0027] Figure 5 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0028] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0029] The dialog request processing method provided in this application embodiment can be applied to, for example, Figure 1In the application environment shown, the dialogue request processing system 101 includes an edge side 102 and a cloud side 103. Users send dialogue requests to the dialogue request processing system via terminal 104. For each received dialogue request, the dialogue request processing system 101 identifies the business semantic keys and business intents included in the dialogue request, constructs a dialogue call chain matrix and a request cancellation token corresponding to the dialogue call chain matrix; each dialogue request contains at least one sub-dialogue request, and each dialogue request corresponds to a unique request cancellation token; based on the dialogue call chain matrix, the dialogue request processing system 101 performs time window shaping and semantic merging on each dialogue request's sub-dialogue requests, generating an edge-merged request set, and establishes a correspondence between the request cancellation tokens and the edge-merged request set, forming a request cancellation mapping table; the dialogue request processing system 101 then performs time window shaping and semantic merging on each dialogue request's sub-dialogue requests according to the business... Semantic keys and business intents are used to generate a cross-layer scheduling instruction set. This set includes a cross-layer deduplication key, with each key corresponding to a business type. The dialogue request processing system 101, based on the request cancellation mapping table and the deduplication keys in the instruction set, retains non-cancelled and non-duplicate sub-dialogue requests, marking them as valid sub-dialogue request sets. The system asynchronously delivers these valid sub-dialogue request sets to the edge-side queue 102 and the cloud-side queue 103, and performs cross-layer parallel processing on the sub-dialogue requests within these queues. The terminal 104 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, smart in-vehicle devices, and projection devices. Portable wearable devices can include smartwatches, smart bracelets, and head-mounted devices. Head-mounted devices can include virtual reality (VR) devices, augmented reality (AR) devices, smart glasses, etc.

[0030] In one exemplary embodiment, such as Figure 2 As shown, a method for processing dialogue requests is provided, which can be applied to... Figure 1 The following steps are used as an example to illustrate the dialogue request processing system 101, including steps 201 to 205. Wherein:

[0031] Step 201: For the received dialogue request, identify the business semantic key and business intent included in the dialogue request, construct a dialogue call chain matrix and a request cancellation token corresponding to the dialogue call chain matrix; the dialogue request contains at least one sub-dialogue request, and each dialogue request corresponds to a unique request cancellation token.

[0032] Among them, cloud center refers to the central data room and server cluster of the charging service platform; edge node refers to the edge computing device deployed at the prefecture-level city or station level; cloud side is synonymous with cloud center, and edge side is synonymous with edge node.

[0033] A dialogue request refers to a complete and independent interactive session between a user and the system, which is a collection of multiple rounds of message interactions centered around a core goal or topic. A sub-dialogue request refers to a secondary interactive session initiated within the same main dialogue request to solve a specific problem, perform a specific task, or handle a branch of the process.

[0034] Business semantic keys refer to the specific information obtained, which may include query area, time period, charging power, vehicle model information, and payment method.

[0035] Business intents can include site query intent, price query intent, queue query intent, route planning intent, payment verification intent, and account query intent.

[0036] Each dialogue request corresponds to a request cancellation token, and the request cancellation tokens of sub-dialogue requests within the same dialogue request are also the same.

[0037] For example, at the edge node, a user input dialogue request is received, the dialogue text, geographical location, account information and historical context of the dialogue request are extracted, and the session identification information of this dialogue request is generated;

[0038] The session identifier information is parsed for intent, and the business intents involved in the session identifier information are identified by keyword matching to form a set of business intents; the business semantic keys in the session identifier information are extracted to form a set of business semantic keys; and key link intents are marked according to preset rules to obtain a set of business intents marked with key tags and a set of business semantic keys; in one embodiment, the preset rules may be to mark business intents involving payment, start / stop charging, and metering reconciliation as key intents, and the rest as general intents; sub-dialogue requests with key intents are marked as key sub-requests, and sub-dialogue requests with general intents are marked as general sub-requests. Based on the stage sequence and dependencies of each business intent, with business type as rows and stage as columns, candidate sub-dialogue requests are mapped into a two-dimensional relation table based on dependencies. Each unit is populated with its business type, business semantic key, stage sequence, and dependency tag, constructing a dialogue call chain matrix. Here, stage represents the execution order of dialogue requests corresponding to each business intent, and dependency represents the dependencies between session requests corresponding to each business intent. In one embodiment, the dependency could be: session request B needs data obtained after session request A is executed; the charging service platform calculates the dialogue-level concurrency quota based on the current load status of the edge nodes. In one embodiment, the load level is determined based on the current load status of the edge side, and the concurrency quota is determined according to the load level. The concurrency quota is determined as follows: the quota is twice the default value when the load is low, the quota is the default value when the load is medium, and the quota is half the default value when the load is high. The quota is preferentially allocated to sub-dialogue requests of key intents, and the remaining quota is allocated to sub-dialogue requests of general intents to obtain the dialogue-level concurrency quota. A unique request cancellation token is generated for this dialogue request, and the request cancellation token is associated with the dialogue call chain matrix and stored in the memory of the edge node. Finally, the dialogue call chain matrix, the dialogue-level concurrency quota, and the request cancellation token are output.

[0039] Step 202: Based on the dialogue call chain matrix, perform time window shaping and semantic merging on the sub-dialogue requests of each dialogue request to generate an edge merge request set, and establish a correspondence between the request cancellation token and the edge merge request set to form a request cancellation mapping table.

[0040] For example, the sub-dialogue request list in the dialogue call chain matrix is ​​read from the edge side. The maximum number of sub-dialogue requests that can be processed in this round is determined based on the dialogue-level concurrency quota. Key sub-dialogue requests are selected first, followed by general sub-dialogue requests, until the dialogue-level concurrency quota limit is reached, forming a set of sub-dialogue requests to be processed. Time window shaping is performed on the set of sub-dialogue requests to be processed. Specifically, the set of sub-dialogue requests to be processed is grouped according to a preset time window length, and the number of sub-dialogue requests in each time window does not exceed the preset window capacity limit. For general sub-dialogue requests, a random delay is added to their planned sending time, ranging from zero to half the window length. Key sub-dialogue requests maintain their original planned sending time or only have a very small delay added. Semantic merging is performed on the time-window shaped sub-dialogue requests. Specifically, requests with the same business intent type and... Sub-dialogue requests with semantic key similarity exceeding a preset similarity threshold are merged into a single merge request. Each merge request records the number and identifier of the original sub-dialogue requests it covers and inherits the key markers of the original sub-dialogue requests. If the merged sub-dialogue requests contain key sub-dialogue requests, the merged request is marked as key; otherwise, it is marked as general, forming an edge merge request set. Request cancellation tokens are mapped to the edge merge request set to form a request cancellation mapping table. Specifically, a two-level mapping relationship is created: the first level maps merge requests to request cancellation tokens, and the second level maps original sub-dialogue requests to merge requests. Request cancellation tokens are associated with each merge request. When a dialogue needs to be cancelled, all merge requests for that dialogue can be quickly located using the request cancellation token, thereby locating all original sub-dialogue requests. The edge merge request set and the request cancellation mapping table are then output.

[0041] In one embodiment, a dialogue-level concurrency quota can be obtained, and then the list of sub-dialogue requests in the dialogue call chain matrix can be read. Based on the dialogue-level concurrency quota, the upper limit of the number of dialogue sub-dialogue requests that can be processed in this round can be determined. In one embodiment, key sub-dialogue requests can be selected first, followed by general sub-dialogue requests, until the upper limit of the dialogue-level concurrency quota is reached, forming a set of sub-dialogue requests to be processed. The dialogue-level concurrency quota refers to the upper limit of the number of sub-dialogue requests that can be processed simultaneously within a single dialogue request.

[0042] Step 203: Generate a cross-layer scheduling instruction set based on the business semantic keys and business intents in the edge merging request set; wherein, the cross-layer scheduling instruction set includes cross-layer deduplication keys; each cross-layer deduplication key corresponds to a business type.

[0043] For example, the cloud side receives an edge merging request set and a request cancellation mapping table, parses the business intent type, business semantic key, number of original sub-dialogue requests covered, and key tags for each merging request in the edge merging request set; calculates the ratio of key sub-dialogue requests to general sub-dialogue requests to obtain request distribution statistics; collects load metrics of various cloud-side tool services, including the current queuing length and cache hit rate of edge nodes, to obtain load status information; and calculates an edge-cloud quota allocation scheme based on the request distribution statistics and load status information. For example, firstly, a minimum quota is reserved on the cloud side for key sub-dialogue requests; secondly, the quota is dynamically allocated based on the load metrics of each tool service. The quota is dynamically adjusted, and finally, the edge quota value and cloud quota value for each type of business intent are determined to form an edge-cloud quota allocation scheme. Based on the business semantic keys in the edge merged request set, cross-layer deduplication keys are determined. The specific method is as follows: according to different business intent types, the corresponding business semantic keys are selected and combined to form a unique identifier for this type of request. At the same time, the cache validity period of each deduplication key is set according to business characteristics. Duplicate requests within the validity period can directly use the cached results. If the validity period is exceeded, it needs to be reprocessed to obtain the cross-layer deduplication rules. The edge-cloud quota allocation scheme and the cross-layer deduplication rules are integrated, and combined with the cancellation token association relationship in the request cancellation mapping table, a cross-layer scheduling instruction set is generated.

[0044] Step 204: Based on the request cancellation mapping table and the cross-layer deduplication key in the cross-layer scheduling instruction set, retain the sub-dialogue requests that have not been cancelled and have not been duplicated in the dialogue request, and mark them as the set of valid sub-dialogue requests.

[0045] For example, the edge node and the cloud side simultaneously receive a cross-layer scheduling instruction set, extract the deduplication key combination method and cache validity period from it, generate a deduplication key identifier for each merge request in the edge merge request set according to the deduplication key combination method, and query the local cache to obtain the deduplication determination result; check the execution status of the current request dialogue, identify the request dialogue that has been completed, timed out, or actively cancelled by the user, and for these dialogues that need to be terminated, find all corresponding merge requests through the cancellation token in the request cancellation mapping table, trace back from the merge request to all original sub-dialogue requests according to the two-level mapping relationship of the request cancellation mapping table, and mark these sub-dialogue requests as pending cancellation. The system obtains a list of requests to be cancelled. For each request in the list, a cancellation operation is performed: if the request is still in the queue, it is removed directly; if the request is being processed, an interrupt signal is sent to the processing process; if the request has been completed but no result has been returned, the result is discarded. The execution result of each cancellation operation is recorded, forming a cancellation receipt record. Based on the deduplication determination result and the cancellation receipt record, the request set is filtered and merged at the edge. Specifically, all items marked as duplicate requests are removed, and all successfully cancelled requests are removed; requests that are neither duplicates nor cancelled are retained, and these requests are renumbered to form a valid sub-dialogue request set. The deduplication determination result is as follows: if the deduplication key exists in the cache and has not exceeded the cache validity period, the request is marked as a duplicate request; if the deduplication key does not exist or has exceeded the cache validity period, it is marked as a non-duplicate request, and the new deduplication key is written to the cache, thus obtaining the deduplication determination result.

[0046] Step 205: Based on the cross-layer scheduling instruction set, the effective sub-dialogue request set is asynchronously delivered to the edge-side queue and the cloud-side queue, and the sub-dialogue requests in the effective sub-dialogue request set are processed in parallel across layers based on the edge-side queue and the cloud-side queue.

[0047] For example, based on the edge-cloud quota allocation scheme in the cross-layer scheduling instruction set, the effective sub-dialogue request set is delivered asynchronously. Specifically, according to the edge and cloud quotas determined by the edge-cloud quota allocation scheme, each request in the effective sub-dialogue request set is assigned to a corresponding processing location. Requests assigned to the edge are delivered to the edge asynchronous processing queue, and requests assigned to the cloud are delivered to the cloud asynchronous processing queue. Each request carries its business intent type, deduplication key identifier, and key marker. The edge and cloud sides process the requests in their respective queues in parallel, generating asynchronous response results. The asynchronous response results are then aggregated to form a dialogue-level summary result. The specific method is as follows: Based on the merging relationship recorded in the edge merge request set, the asynchronous response result is mapped back to the corresponding original sub-dialogue request. The results of each sub-dialogue request are assembled according to the stage sequence and dependency relationship in the dialogue call chain matrix to form a dialogue-level summary result. At the same time, the edge processing time, cloud-side processing time, cancellation request ratio and deduplication hit rate are recorded to form performance statistics. Based on the performance statistics and cancellation receipt records, the dialogue-level concurrency quota and time window shaping parameters are adjusted to obtain an adaptive parameter set, which is stored in the edge node so that the dialogue-level concurrency quota and time window can be adjusted according to the adaptive parameter set.

[0048] In the above-mentioned method for processing dialogue requests, for each received dialogue request, the business semantic key and business intent included in the dialogue request are identified, and a dialogue call chain matrix and a request cancellation token corresponding to the dialogue call chain matrix are constructed. Each dialogue request contains at least one sub-dialogue request, and each dialogue request corresponds to a unique request cancellation token. Based on the dialogue call chain matrix, time window shaping and semantic merging are performed on the sub-dialogue requests of each dialogue request to generate an edge-merged request set, and a correspondence is established between the request cancellation token and the edge-merged request set to form a request cancellation mapping table. Based on the business semantic key and business intent in the edge-merged request set, a cross-layer scheduling instruction set is generated. The cross-layer scheduling instruction set includes a cross-layer deduplication key. Each cross-layer deduplication key corresponds to a business type. Based on the request cancellation mapping table and the cross-layer deduplication key in the cross-layer scheduling instruction set, the uncancelled and non-duplicate sub-dialogue requests in the dialogue request are retained and marked as valid sub-dialogue request sets. Based on the cross-layer scheduling instruction set, the valid sub-dialogue request sets are asynchronously delivered to the edge-side queue and the cloud-side queue, and the sub-dialogue requests in the valid sub-dialogue request sets are processed in cross-layer parallel processing based on the edge-side queue and the cloud-side queue. By constructing a dialogue call chain matrix and request cancellation tokens based on the business semantic keys and business intents of dialogue requests, semantic merging is performed according to the dialogue call chains. This enables the merging of semantically identical sub-dialogue requests, preventing the same queries from being processed multiple times and reducing unnecessary load. A correspondence is established between the request cancellation tokens and the edge merged request set, forming a request cancellation mapping table. This allows for accurate identification of semantically duplicated sub-dialogue requests using the request cancellation tokens. Then, the business semantic keys and business intents in the edge merged request set generate a cross-layer scheduling instruction set. This cross-layer instruction scheduling set can promptly terminate invalid sub-dialogue requests, preventing them from continuing to execute on the edge or cloud side, consuming valuable resources and increasing concurrency pressure. Finally, based on the request cancellation mapping table and the cross-layer deduplication keys in the cross-layer scheduling instruction set, non-cancelled and non-duplicate sub-dialogue requests are retained and marked as valid sub-dialogue request sets. These valid sub-dialogue request sets prevent invalid or already executed dialogue requests from continuing to execute, effectively achieving cross-layer deduplication and merging. By leveraging the dialogue call chain matrix, request cancellation mapping table, cross-layer scheduling instruction set, and effective sub-dialogue request set, the system can effectively deduplicate sub-dialogue requests and promptly remove invalid sub-dialogue requests. This also prevents a sub-dialogue request from being executed repeatedly on both the cloud and edge sides, reducing load and improving processing efficiency.

[0049] In one exemplary embodiment, such as Figure 3 As shown, constructing the dialogue call chain and requesting the cancellation token includes steps 301 to 303. Wherein:

[0050] Step 301: Based on the intent parsing and business semantic keys of the dialogue requests, obtain the dependencies and stage sequences between each sub-dialogue request.

[0051] Among these, business intents include, but are not limited to, site query intent, price query intent, queue query intent, route planning intent, payment verification intent, and account query intent.

[0052] Business semantic keys include query content, including but not limited to query region, time period, charging power, vehicle model information, and payment method.

[0053] The phase sequence between sub-dialogue requests represents the order in which they are executed, and the dependency relationship represents the data dependency relationship between the sub-dialogue requests. In one embodiment, a site query must first execute a price query, and a queue query depends on the site query result. Route planning depends on the site query result, and payment verification depends on the price query result. For example, site query is the first phase, price and queue are the second phase and depend on the first phase, route planning is the third phase and depends on the first phase, and payment verification is the fourth phase and depends on the second phase.

[0054] For example, at the edge node, a user input dialogue request is received, and the dialogue text, geographical location, account information, and historical context of the dialogue request are extracted to generate the session identification information for this dialogue request. The session identification information is then parsed for intent. In one embodiment, the business intent involved in the session identification information can be identified by matching preset keywords to form a set of business intents. The business semantic keys in the session identification information are extracted to form a set of business semantic keys. And the key link intents are labeled according to preset rules to obtain a set of business intents and a set of business semantic keys with key tags.

[0055] The preset rules can be as follows: business intentions involving payment, charging start / stop, and metering reconciliation are marked as critical intentions, and all others are marked as general intentions; dialogue requests with critical intentions are marked as critical sub-dialogue requests, and dialogue requests with general intentions are marked as general sub-dialogue requests. Critical dialogue requests have higher execution priority than general dialogue requests. Correspondingly, critical sub-dialogue requests have higher execution priority than general sub-dialogue requests.

[0056] Step 302: Based on the dependency relationship, the sub-dialogue request is mapped into a two-dimensional relation table. The business type is used as the row of the two-dimensional relation table, and the stage is used as the column of the two-dimensional relation table. The target data is then filled into each cell of the two-dimensional relation table to obtain the dialogue call chain matrix. The target data includes business intent, business semantic key, stage sequence and dependency tag. The dependency tag is obtained according to the dependency relationship.

[0057] For example, the phase sequence and dependencies of each intent are determined based on business logic. With business type as the row and phase as the column, the candidate sub-dialogue requests are mapped into a two-dimensional relation table based on the dependencies. The business type, business semantic key, phase sequence and dependency tag of each unit are filled in to form a dialogue call chain matrix.

[0058] Step 303: Generate a unique request cancellation token for each dialogue request, and establish a correspondence between the request cancellation token and the dialogue call chain matrix and store it in the edge memory.

[0059] For example, a request cancellation token is generated by combining session identification information with the current timestamp into a string, and then generating a fixed-length unique identifier through a hash operation. The unique identifier is the request cancellation token.

[0060] The session identifier information of each dialogue request is combined with the current timestamp to obtain a string, and then the string is hashed to obtain a new string.

[0061] In this embodiment, the dependency relationships and stage sequences between sub-dialogues are generated through intent parsing and business semantic keys, and mapped into a two-dimensional relationship table: rows represent business types and lists represent stages, which can intuitively identify the dependency chain (i.e., dialogue call chain) of sub-dialogue requests.

[0062] In one embodiment, based on the dialogue call chain matrix, time window shaping and semantic merging are performed on the sub-dialogue requests of each dialogue request to generate an edge-merged request set. A correspondence is then established between the request cancellation token mapping and the edge-merged request set to form a request cancellation mapping table, including:

[0063] In the dialogue call chain matrix, sub-dialogue requests with the same business intent type and a business semantic key similarity exceeding a preset similarity threshold are identified. The identified sub-dialogue requests are merged to obtain a merged request, a merged request identifier, and a marker information for the merged request. The marker information represents the processing priority of the merged request.

[0064] Based on all merge requests, obtain the edge merge request set;

[0065] Establish a first mapping relationship and a second mapping relationship; the first mapping relationship represents the mapping relationship between the merge request identifier and the request cancellation token; the second mapping relationship represents the mapping relationship between the original sub-dialogue request and the request cancellation token; the original sub-dialogue request represents the sub-dialogue request before merging to obtain the edge merge request set.

[0066] The tagging information includes general sub-dialogue requests and key sub-dialogue requests.

[0067] The method for determining semantic key similarity is as follows: Based on the type of semantic key, a similarity threshold is determined, and then the semantic key similarity is judged based on the similarity threshold. For geographic location semantic keys, the distance difference is calculated; if the distance difference is less than a preset distance threshold, the keys are considered similar. For time-related semantic keys, the time difference is calculated; if two sub-dialogue requests exist within the same time window, the two sub-dialogue requests are considered similar. For enumeration-type semantic keys such as power level and vehicle model, if they are completely identical, they are considered similar.

[0068] For example, the list of sub-dialogue requests in the dialogue call chain matrix is ​​read, the upper limit of the number of sub-dialogue requests that can be processed in this round is determined according to the dialogue-level concurrency quota, key sub-dialogue requests are selected first, then general sub-dialogue requests are selected, until the dialogue-level concurrency quota upper limit is reached, forming a set of sub-dialogue requests to be processed.

[0069] The set of pending sub-dialogue requests is grouped according to a preset time window length, with the number of sub-dialogue requests within each time window not exceeding the window capacity limit. For general sub-dialogue requests, a random delay is added to their planned sending time, ranging from zero to half the window length, to ensure that the sending time of sub-dialogue requests is evenly distributed within the window and to avoid excessive instantaneous concurrency. Critical sub-dialogue requests maintain their original planned sending time or only have a minimal delay added to ensure priority processing. The preset time window can be pre-set, and its size must be smaller than the dialogue-level concurrency quota.

[0070] Sub-dialogue requests with the same business intent type and semantic key similarity exceeding a preset similarity threshold are identified and merged into a single merged request. The merged request retains the identifier list of the original sub-dialogue requests for subsequent result distribution. In one embodiment, for site query requests, if the query areas overlap and the time periods are the same, they are merged into one request; for price query requests, if the sites are the same and the charging power levels are the same, they are merged into one request. Each merged request records the number and identifiers of the original sub-dialogue requests it covers and inherits the key markers of the original sub-dialogue requests. If the merged sub-dialogue requests contain key sub-dialogue requests, the merged request is marked as key; otherwise, it is marked as general, forming an edge merged request set.

[0071] The request cancellation token is mapped to the edge merge request set to form a request cancellation mapping table. Specifically, a two-level mapping relationship is created: the first level is a mapping from merge requests to request cancellation tokens, used to mark the dialogue to which each merge request belongs; the second level is a mapping from original sub-dialogue requests to merge requests, used to track the merge affiliation of sub-dialogue requests. The request cancellation token is associated with each merge request. When a dialogue needs to be cancelled, all merge requests for that dialogue can be quickly located through the request cancellation token, and then all original sub-dialogue requests can be located. It should be noted that the original sub-dialogue request identifier is a unique identifier of the unmerged sub-dialogue request extracted from the dialogue call chain matrix.

[0072] In one embodiment, during semantic merging, multiple original sub-dialogue requests may be merged into a single merge request. However, the merge request retains a list of all merged original sub-dialogue request identifiers to ensure that the results are correctly distributed back to each original sub-dialogue request after the session request is completed. The output includes an edge merge request set and a request cancellation mapping table. The edge merge request set contains a list of merged requests, the planned sending time for each request, and the identifiers of the original sub-dialogue requests it covers. The request cancellation mapping table contains a mapping between tokens and merge requests, as well as a mapping between sub-dialogue requests and merge requests, for use in subsequent steps.

[0073] In one embodiment, the conversation-level concurrency quota can be calculated based on the current load status of the edge node. Specifically, the load level is determined based on the current load status of the edge node, and the concurrency quota is determined based on the load level. The concurrency quota is determined as follows: the concurrency quota is twice the default value when the load is low, the concurrency quota is the default value when the load is medium, and the concurrency quota is half the default value when the load is high. The concurrency quota is preferentially allocated to sub-conversation requests of critical intents to ensure that critical services are allocated at least the minimum guaranteed number, and the remaining quota is allocated to conversation sub-conversation requests of general intents to obtain the conversation-level concurrency quota.

[0074] For example, the current load status on the edge side can be used to determine the load level by: counting the number of queues waiting on the edge side and the recent average response time; if the number of queues waiting is less than a preset waiting threshold (e.g., 100 requests) and the recent average response time does not exceed a preset response time baseline (e.g., 200 milliseconds), it is determined to be low load; if the number of queues waiting is within a preset waiting range (e.g., 70-100 requests) or the recent average response time exceeds the preset response time baseline but does not exceed the preset response time upper limit (e.g., 400 milliseconds), it is determined to be medium load; if the number of queues waiting exceeds the preset waiting threshold or the recent average response time exceeds the preset response time upper limit, it is determined to be high load.

[0075] In one embodiment, a cross-layer scheduling instruction set is generated based on the business semantic key and business intent in the edge merging request set, including:

[0076] The tagging information of each sub-dialogue request in the edge merging request set is counted separately to obtain the request distribution statistics;

[0077] Load metrics of each tool service on the edge and cloud sides are collected separately to obtain load status information for each side. The load metrics include the current queue length on the edge side, the queue length on the cloud side, the cache hit rate on the edge side, and the cache hit rate on the cloud side. Each tool service is responsible for processing a sub-dialogue request for a specific business intent.

[0078] Based on the request distribution statistics and the respective load status information of the edge and cloud sides, edge quota values ​​and cloud quota values ​​are allocated to sub-dialogue requests for each type of business intent to obtain the edge-cloud quota allocation scheme.

[0079] Based on the business semantic keys and business intents in the edge merging request set, the cross-layer deduplication key and the cache validity period of the cross-layer deduplication key are obtained, and the cross-layer deduplication rules are obtained based on the cross-layer deduplication key and the cache validity period.

[0080] By integrating the edge-cloud quota allocation scheme with cross-layer deduplication rules and combining the cancellation token association in the request cancellation mapping table, a cross-layer scheduling instruction set is generated.

[0081] Tool services refer to the core technology system that encapsulates external functional modules (such as APIs, local programs, and third-party services) into standardized, reusable service units, integrates with the dialogue system through a unified interface, and supports complex business logic (such as data querying, process approval, and resource operation). This can include information such as available parking spaces, queue times, prices and discounts, route planning, payment, accounts, and orders.

[0082] For example, the cloud side receives the edge merging request set and the request cancellation mapping table, parses the business intent type, business semantic key, number of original sub-dialogue requests covered, and key tags of each merging request in the edge merging request set; calculates the ratio of key sub-dialogue requests to general sub-dialogue requests to obtain request distribution statistics; and collects load indicators of various cloud-side tool services, including the current queue length and the cache hit rate of edge nodes, to obtain load status information.

[0083] The edge-cloud quota allocation scheme is calculated based on request distribution statistics and load status information. The specific method is as follows: First, a minimum quota is reserved on the cloud side for critical sub-dialogue requests to ensure reliable processing of critical business operations. Second, the quota is dynamically adjusted according to the load indicators of each tool service. Finally, the edge quota value and cloud quota value for each type of business intent are determined to form the edge-cloud quota allocation scheme. In a specific embodiment, for example: request distribution statistics show a total of 50 merged requests, including 15 critical sub-requests and 35 general sub-requests; load status shows that the queue length of the cloud-side site query service exceeds the preset queue length threshold, and the edge node site query cache hit rate reaches 80%. When the system executes quota allocation, it first reserves quotas on the cloud side for all 15 critical sub-requests; then, it prioritizes allocating site query requests from the 35 general sub-requests to edge processing (25 requests) and cloud processing (10 requests). The final edge-cloud quota allocation scheme is: 25 quotas allocated to the edge and 25 quotas allocated to the cloud.

[0084] By collecting load metrics of various tool services on both the edge and cloud sides, the load status information of each side can be obtained as follows: when the queue length of a certain type of service exceeds the preset queue length threshold, a portion of the quota for that type of request is transferred to the edge node; for business types whose cache hit rate on the edge node is higher than the preset cache hit rate threshold, the proportion of their edge quota is increased.

[0085] Based on different business intent types, corresponding business semantic keys are selected and combined to form a unique identifier for that type of dialogue request. Simultaneously, the cache validity period for each deduplication key is set according to the business characteristics corresponding to the dialogue request. A longer validity period is set for price information that changes slowly, and a shorter validity period is set for queuing information that changes quickly. Duplicate requests within the validity period can directly use the cached results; requests exceeding the validity period need to be reprocessed, resulting in cross-layer deduplication rules. In one embodiment, for site query requests, the two business semantic keys, query region and time period, are combined to form "query region - time period" as the deduplication key. When two requests have the same deduplication key, they are considered duplicate requests, and only the first one is processed; subsequent identical requests directly return the result of the first request. In a specific embodiment, the cache validity period is: 24 hours for price information, 12 hours for basic site information, 10 minutes for queuing information, and 30 minutes for route information.

[0086] By integrating the edge-cloud quota allocation scheme with cross-layer deduplication rules and combining the cancellation token association in the request cancellation mapping table, a cross-layer scheduling instruction set is generated. The cross-layer scheduling instruction set includes: the specific values ​​of edge quota and cloud quota for various business intents, the deduplication key combination method and cache validity period for each type of request, and the cancellation path associated with the request cancellation token. The cross-layer scheduling instruction set is simultaneously distributed to edge nodes and various cloud-side tool services to ensure that both ends execute according to unified rules and output the cross-layer scheduling instruction set.

[0087] It should be noted that the deduplication key combination method is as follows: for site query, use "query area - time period", for price query, use "site identifier - charging power", for queue query, use "site identifier - current time window", for route planning, use "starting point - ending point", and for payment verification, use "order identifier".

[0088] In a specific embodiment, for example, the edge merging request set contains three merging requests: the first is a site query request, whose business semantic key includes the query area as "Haidian District" and the time period as "14:00-15:00"; the second is also a site query request, whose business semantic key includes the query area as "Haidian District" and the time period as "14:00-15:00"; the third is a price query request, whose business semantic key includes the site identifier as "West Station Charging Station 001" and the charging power as "60 kilowatts". When performing cross-layer deduplication, the system extracts the business semantic key "Haidian District" and "14:00-15:00" from the first request, combining them to form the deduplication key "Haidian District-14:00-15:00", and sets a 12-hour cache validity period. When processing the second request, it finds that its combined deduplication key is also "Haidian District-14:00-15:00", identical to the first request, and within the validity period. Therefore, the second request is marked as a duplicate, and no further query is made to the cloud side; instead, the system waits for the result of the first request and reuses it directly. For the third request, the system extracts the business semantic key "West Station Charging Station 001" and "60 kW", combining them to form the deduplication key "West Station Charging Station 001 kW-60 kW", and sets a 24-hour cache validity period. Since this deduplication key appears for the first time, the request is processed normally. In this way, the system avoids repeated queries for the same information, reduces the processing pressure on the cloud side, and improves overall response efficiency.

[0089] In one embodiment, based on the request cancellation mapping table and the cross-layer deduplication key in the cross-layer scheduling instruction set, the non-cancelled and non-duplicate sub-dialogue requests in the dialogue request are retained and marked as a valid set of sub-dialogue requests, including:

[0090] Extract the deduplication key and the corresponding preset cache validity period from the cross-layer scheduling instruction set, and confirm the deduplication judgment results of the edge side and the cloud side respectively;

[0091] Get the execution status of all sub-dialogue requests;

[0092] If a sub-dialogue request has an execution status that corresponds to the target execution status, then based on the cancellation token in the request cancellation mapping table, find all merge requests that correspond to the sub-dialogue request with the target execution status; where the target execution status indicates that the processing needs to be terminated.

[0093] Based on the request cancellation mapping table, determine the original sub-dialogue request corresponding to the merge request, and obtain the list of requests to be cancelled;

[0094] Perform a termination operation on the list of cancellation requests and obtain a cancellation receipt record;

[0095] Based on the deduplication results and cancellation receipt records from both the edge and cloud sides, duplicate and cancelled dialogue requests are removed from the sub-dialogue requests to obtain a set of valid sub-dialogue requests.

[0096] The target execution status represents the state that needs to be terminated, which may include the completed state, the timed-out state, and the user-initiated cancellation state.

[0097] For example, if the deduplication key exists in the cache and the cache validity period has not expired, both the edge side and the cloud side mark the dialogue request as a duplicate dialogue request. If the deduplication key does not exist or the cache validity period has expired, it is marked as a non-duplicate dialogue request, and the new deduplication key is written to the cache to obtain the deduplication determination result. The execution status of all sub-dialogue requests is obtained. If a sub-dialogue request is in the target execution state, then all corresponding merged dialogue requests are found through the cancellation token in the dialogue request cancellation mapping table. Based on the two-level mapping relationship of the dialogue request cancellation mapping table, the merged dialogue request is traced back to all original sub-dialogue requests, and these sub-dialogue requests are marked as pending cancellation to obtain a list of pending cancellation dialogue requests.

[0098] If the confirmation request from the edge side is still waiting in the edge side queue, it is removed directly from the edge side queue; if the confirmation request from the cloud side is still waiting in the edge side queue, it is removed directly from the cloud side queue; if the request is being processed, an interrupt signal is sent to the processing process; if the request has been completed but no result has been returned, the result is discarded; the execution result of each cancellation operation is recorded to form a cancellation receipt record.

[0099] Based on the deduplication judgment results and cancellation receipt records, the edge merged dialogue request set is filtered. The specific method is as follows: both the edge side and the cloud side remove all items marked as duplicate dialogue requests and all successfully cancelled dialogue requests; retain dialogue requests that are neither duplicates nor cancelled. Then, the edge side and the cloud side interact to confirm the dialogue requests that are neither duplicates nor cancelled on both sides, and renumber these dialogue requests to form a valid sub-dialogue request set.

[0100] In one embodiment, for example: the edge merged dialogue request set contains 10 merged dialogue requests. After deduplication, the edge side and the cloud side find that the deduplication key of 3 dialogue requests is the same as the existing record in the cache and is within the validity period, so they are marked as duplicates. The edge side and the cloud side respectively detect that a certain dialogue has timed out, find the 2 merged dialogue requests associated with the dialogue through the dialogue request cancellation mapping table, perform the cancellation operation and generate a receipt. Finally, after filtering, 5 valid sub-dialogue requests are obtained. These 5 dialogue requests are neither duplicates nor canceled, and can continue to be processed.

[0101] In one embodiment, asynchronously delivering a set of valid sub-dialogue requests to edge-side queues and cloud-side queues based on a cross-layer scheduling instruction set includes:

[0102] Based on the edge-cloud quota allocation scheme in the cross-layer scheduling instruction set, the edge quota value and cloud quota value corresponding to the sub-dialogue request of each business intent are determined, and each sub-dialogue request in the valid sub-dialogue request set is allocated to the corresponding target processing position according to the business intent; wherein, the target processing position is one of the cloud-side queue and the edge-side queue.

[0103] For example, based on the edge quota and cloud quota determined by the edge-cloud quota allocation scheme, each dialogue request in the effective sub-dialogue request set is assigned to the corresponding processing location. Dialogue requests assigned to the edge are delivered to the edge asynchronous processing queue, and dialogue requests assigned to the cloud are delivered to the cloud asynchronous processing queue. Each dialogue request carries its business intent type, deduplication key identifier, and key tag. The edge and cloud sides process the dialogue requests in their respective queues in parallel to generate asynchronous response results.

[0104] Based on the merging relationship recorded in the edge merged dialogue request set, the asynchronous response results are mapped back to the corresponding original sub-dialogue requests. The results of each sub-dialogue request are assembled according to the stage sequence and dependency relationship in the dialogue call chain matrix to form a dialogue-level summary result. At the same time, the edge processing time, cloud processing time, percentage of canceled dialogue requests and deduplication hit rate are recorded to form performance statistics.

[0105] Based on performance statistics and cancellation receipt records, the dialogue-level concurrency quota and time window shaping parameters are adjusted to obtain an adaptive parameter set, which is stored in the edge node. The adjusted dialogue-level concurrency quota, edge quota ratio, cache validity period, and random latency range are combined to form the adaptive parameter set.

[0106] In one embodiment, when the proportion of canceled dialogue requests exceeds a first preset threshold (e.g., 15%), the dialogue-level concurrency quota is reduced by a first preset ratio (e.g., 10%); when the edge processing time is less than a preset multiple (e.g., 1.5 times) of the cloud-side processing time, the edge quota proportion is increased by a second preset ratio (e.g., 8%); when the deduplication hit rate exceeds a second preset threshold (e.g., 30%), the cache validity period is extended by a third preset ratio (e.g., 20%); when uneven distribution of dialogue request time is detected, the random delay range in the time window shaping is increased (e.g., from 5 milliseconds to 30 milliseconds).

[0107] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0108] Based on the same inventive concept, this application also provides a dialog request processing apparatus for implementing the dialog request processing method described above. The solution provided by this apparatus is similar to the implementation described in the above method; therefore, the specific limitations of one or more dialog request processing apparatus embodiments provided below can be found in the limitations of the dialog request processing method described above, and will not be repeated here.

[0109] In one exemplary embodiment, such as Figure 4 As shown, a dialog request processing apparatus is provided, comprising: an identification construction module 401, a generation forming module 402, a generation module 403, a tag retention module 404, and a cross-layer parallel module 405, wherein:

[0110] The identification construction module 401 is used to identify the business semantic key and business intent included in the received dialogue request, construct a dialogue call chain matrix and a request cancellation token corresponding to the dialogue call chain matrix; the dialogue request contains at least one sub-dialogue request, and each dialogue request corresponds to a unique request cancellation token;

[0111] The generation module 402 is used to perform time window shaping and semantic merging on the sub-dialogue requests of each dialogue request according to the dialogue call chain matrix, generate an edge merging request set, and establish a correspondence between the request cancellation token and the edge merging request set to form a request cancellation mapping table.

[0112] The generation module 403 is used to generate a cross-layer scheduling instruction set based on the business semantic keys and business intents in the edge merging request set; wherein, the cross-layer scheduling instruction set includes a cross-layer deduplication key; each cross-layer deduplication key corresponds to a business type;

[0113] The retention marking module 404 is used to retain the non-cancelled and non-duplicate sub-dialogue requests in the dialogue request based on the request cancellation mapping table and the cross-layer deduplication key in the cross-layer scheduling instruction set, and mark them as a valid sub-dialogue request set.

[0114] The cross-layer parallel module 405 is used to asynchronously deliver the effective sub-dialogue request set to the edge-side queue and the cloud-side queue based on the cross-layer scheduling instruction set, and to perform cross-layer parallel processing on the sub-dialogue requests in the effective sub-dialogue request set based on the edge-side queue and the cloud-side queue.

[0115] In an optional embodiment, the identification building module 401 is further configured to:

[0116] Based on the intent parsing and business semantic keys of the dialogue requests, the dependencies and stage sequences between the sub-dialogue requests are obtained.

[0117] Based on dependencies, sub-dialogue requests are mapped to a two-dimensional relation table. The business type is used as the row and the stage as the column of the two-dimensional relation table. The target data is then filled into each cell of the two-dimensional relation table to obtain a dialogue call chain matrix. The target data includes business intent, business semantic key, stage sequence and dependency tag. The dependency tag is obtained based on the dependency relationship.

[0118] A unique request cancellation token is generated for each dialogue request, and the request cancellation token is associated with the dialogue call chain matrix and stored in the edge memory.

[0119] In an optional embodiment, the generation forming module 402 is further configured to:

[0120] In the dialogue call chain matrix, sub-dialogue requests with the same business intent type and a business semantic key similarity exceeding a preset similarity threshold are identified. The identified sub-dialogue requests are merged to obtain a merged request, a merged request identifier, and a marker information for the merged request. The marker information represents the processing priority of the merged request.

[0121] Based on all merge requests, obtain the edge merge request set;

[0122] Establish a first mapping relationship and a second mapping relationship; the first mapping relationship represents the mapping relationship between the merge request identifier and the request cancellation token; the second mapping relationship represents the mapping relationship between the original sub-dialogue request and the request cancellation token; the original sub-dialogue request represents the sub-dialogue request before merging to obtain the edge merge request set.

[0123] In an optional embodiment, the generation module 403 is further configured to:

[0124] The tagging information of each sub-dialogue request in the edge merging request set is counted separately to obtain the request distribution statistics;

[0125] Load metrics of each tool service on the edge and cloud sides are collected separately to obtain load status information for each side. The load metrics include the current queue length on the edge side, the queue length on the cloud side, the cache hit rate on the edge side, and the cache hit rate on the cloud side. Each tool service is responsible for processing a sub-dialogue request for a specific business intent.

[0126] Based on the request distribution statistics and the respective load status information of the edge and cloud sides, edge quota values ​​and cloud quota values ​​are allocated to sub-dialogue requests for each type of business intent to obtain the edge-cloud quota allocation scheme.

[0127] Based on the business semantic keys and business intents in the edge merging request set, the cross-layer deduplication key and the cache validity period of the cross-layer deduplication key are obtained, and the cross-layer deduplication rules are obtained based on the cross-layer deduplication key and the cache validity period.

[0128] By integrating the edge-cloud quota allocation scheme with cross-layer deduplication rules and combining the cancellation token association in the request cancellation mapping table, a cross-layer scheduling instruction set is generated.

[0129] In an optional embodiment, the marker retention module 404 is further configured to:

[0130] Extract the deduplication key and the corresponding preset cache validity period from the cross-layer scheduling instruction set, and confirm the deduplication judgment results of the edge side and the cloud side respectively;

[0131] Get the execution status of all sub-dialogue requests;

[0132] If a sub-dialogue request has an execution status that corresponds to the target execution status, then based on the cancellation token in the request cancellation mapping table, find all merge requests that correspond to the sub-dialogue request with the target execution status; where the target execution status indicates that the processing needs to be terminated.

[0133] Based on the request cancellation mapping table, determine the original sub-dialogue request corresponding to the merge request, and obtain the list of requests to be cancelled;

[0134] Perform a termination operation on the list of cancellation requests and obtain a cancellation receipt record;

[0135] Based on the deduplication results and cancellation receipt records from both the edge and cloud sides, duplicate and cancelled dialogue requests are removed from the sub-dialogue requests to obtain a set of valid sub-dialogue requests.

[0136] In an optional embodiment, the cross-layer parallel module 405 is further configured to:

[0137] Based on the edge-cloud quota allocation scheme in the cross-layer scheduling instruction set, the edge quota value and cloud quota value corresponding to the sub-dialogue request of each business intent are determined, and each sub-dialogue request in the valid sub-dialogue request set is allocated to the corresponding target processing position according to the business intent; wherein, the target processing position is one of the cloud-side queue and the edge-side queue.

[0138] The modules in the aforementioned dialogue request processing device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can invoke and execute the operations corresponding to each module.

[0139] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 5As shown, this computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores dialog requests. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When the computer program is executed by the processor, it implements a dialog request processing method.

[0140] Those skilled in the art will understand that Figure 5 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0141] In one embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above method embodiments.

[0142] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above method embodiments.

[0143] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0144] 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, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0145] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0146] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0147] The above embodiments are merely illustrative of several implementation methods of this application, and their descriptions are relatively specific and detailed. However, they should not be construed as limiting the scope of this application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method of processing a dialog request, characterized by, The method is applied to a dialogue request processing system, the dialogue request processing system comprises a cloud side and an edge side, and the method comprises the following steps: For a received dialogue request, the business semantic key and the business intent included in the dialogue request are identified, a dialogue call chain matrix and a request cancellation token corresponding to the dialogue call chain matrix are constructed; the dialogue request comprises at least one sub-dialogue request, and each dialogue request corresponds to a unique request cancellation token; According to the dialogue call chain matrix, the time window shaping and semantic merging are performed on the sub-dialogue requests of each dialogue request, an edge merging request set is generated, the request cancellation token is associated with the edge merging request set to form a request cancellation mapping table; According to the business semantic key and the business intent in the edge merging request set, a cross-layer scheduling instruction set is generated; wherein the cross-layer scheduling instruction set comprises a cross-layer deduplication key; each cross-layer deduplication key corresponds to a business type; According to the request cancellation mapping table and the cross-layer deduplication key in the cross-layer scheduling instruction set, the sub-dialogue requests in the dialogue request that are not cancelled and not repeated are retained and marked as an effective sub-dialogue request set; Based on the cross-layer scheduling instruction set, the effective sub-dialogue request set is asynchronously delivered to an edge side queue and a cloud side queue, and the sub-dialogue requests in the effective sub-dialogue request set are processed in parallel across layers based on the edge side queue and the cloud side queue.

2. The method of claim 1, wherein, The construction of the dialogue call chain matrix and the request cancellation token corresponding to the dialogue call chain matrix comprises: Based on the intent analysis and business semantic key of the dialogue request, the dependency relationship and stage sequence between the sub-dialogue requests are obtained; Based on the dependency relationship, the sub-dialogue requests are mapped into a two-dimensional relationship table, the business type is taken as the row of the two-dimensional relationship table, the stage is taken as the column of the two-dimensional relationship table, and target data is filled into each cell in the two-dimensional relationship table to obtain the dialogue call chain matrix; wherein the target data comprises a business intent, the business semantic key, the stage sequence and a dependency mark; the dependency mark is obtained according to the dependency relationship; A unique request cancellation token is generated for each dialogue request, and the request cancellation token is associated with the dialogue call chain matrix and stored in the edge side memory.

3. The method of claim 2, wherein, According to the dialogue call chain matrix, the time window shaping and semantic merging are performed on the sub-dialogue requests of each dialogue request, an edge merging request set is generated, the request cancellation token is associated with the edge merging request set to form a request cancellation mapping table, which comprises: Identify the sub-dialogue requests in the dialogue call chain matrix that have the same business intent type and the business semantic key similarity exceeding a preset similarity threshold, and perform merging processing on the identified sub-dialogue requests to obtain a merged request, a merged request identifier and marking information of the merged request; wherein the marking information represents the processing priority of the merged request; According to all the merged requests, an edge merging request set is obtained; establish a first mapping relationship and a second mapping relationship; the first mapping relationship represents a mapping relationship between the merging request identifier and the request cancellation token; the second mapping relationship represents a mapping relationship between an original sub-conversation request and the request cancellation token; the original sub-conversation request represents a sub-conversation request before the edge merging request set is obtained by merging.

4. The method of claim 3, wherein, The generating, according to the service semantic key and the service intent in the edge merging request set, a cross-layer scheduling instruction set comprises: respectively, the label information of each sub-conversation request in the edge merging request set is counted to obtain request distribution statistics; respectively, the load indicators of each tool service on the edge side and the cloud side are collected to obtain the load state information of the edge side and the cloud side respectively; wherein, the load indicators include the current queue length on the edge side, the queue length on the cloud side, the cache hit rate on the edge side and the cache hit rate on the cloud side; wherein, each kind of tool service corresponds to processing a sub-conversation request of one kind of service intent; According to the request distribution statistics and the load state information of the edge side and the cloud side respectively, the edge quota value and the cloud quota value are allocated for each sub-conversation request of one kind of service intent to obtain an edge-cloud quota allocation scheme; According to the service semantic key and the service intent in the edge merging request set, a cross-layer deduplication key and a cache valid time length of the cross-layer deduplication key are obtained, and a cross-layer deduplication rule is obtained according to the cross-layer deduplication key and the cache valid time length; Integrate the edge-cloud quota allocation scheme and the cross-layer deduplication rule, combine the cancellation token association relationship in the request cancellation mapping table, and generate the cross-layer scheduling instruction set.

5. The method of claim 4, wherein, According to the request cancellation mapping table, the cross-layer deduplication key in the cross-layer scheduling instruction set, the sub-conversation request in the conversation request which is not cancelled and not repeated is retained, and is marked as an effective sub-conversation request set, comprising: Extract the deduplication key in the cross-layer scheduling instruction set and the preset cache valid time length corresponding to the deduplication key, and confirm the deduplication judgment result of the edge side and the cloud side respectively; Obtain the execution state of all sub-conversation requests; If the execution state of the sub-conversation request is a target execution state, according to the cancellation token in the request cancellation mapping table, find all merging requests which have a corresponding relationship with the sub-conversation request of the target execution state; wherein, the target execution state represents a need to terminate processing; According to the request cancellation mapping table, determine the original sub-conversation request corresponding to the merging request to obtain a to-be-cancelled request list; Perform a termination operation on the to-be-cancelled request list to obtain a cancellation receipt record; According to the cross-layer deduplication key in the cross-layer scheduling instruction set and the cancellation receipt record, respectively, remove the repeated conversation requests and the cancelled conversations in the sub-conversation request to obtain the effective sub-conversation request set.

6. The method of claim 4, wherein, The asynchronous delivery of the effective sub-conversation request set to the edge side queue and the cloud side queue based on the cross-layer scheduling instruction set comprises: According to the edge cloud quota allocation scheme in the cross-layer scheduling instruction set, the edge quota value and the cloud side quota value corresponding to each service intention sub-conversation request are determined, and each sub-conversation request in the effective sub-conversation request set is allocated to a corresponding target processing position according to the service intention; wherein the target processing position is one of the cloud side queue and the edge side queue.

7. An apparatus for processing a session request, characterized by The apparatus comprises: An identification module configured to identify, for a received conversation request, a service semantic key and a service intention included in the conversation request, construct a conversation call chain matrix and a request cancellation token corresponding to the conversation call chain matrix; the conversation request comprises at least one sub-conversation request, and each conversation request corresponds to a unique request cancellation token; A generation module configured to perform time window shaping and semantic merging on each sub-conversation request of the conversation request according to the conversation call chain matrix, generate an edge merged request set, and establish a corresponding relationship between the request cancellation token and the edge merged request set to form a request cancellation mapping table; A generation module configured to generate a cross-layer scheduling instruction set according to the service semantic key and the service intention in the edge merged request set; wherein the cross-layer scheduling instruction set comprises a cross-layer deduplication key; each cross-layer deduplication key corresponds to a service type; A reservation marking module configured to reserve, according to the request cancellation mapping table and the cross-layer deduplication key in the cross-layer scheduling instruction set, a sub-conversation request in the conversation request that has not been cancelled and has not been duplicated, and mark it as an effective sub-conversation request set; A cross-layer parallel module configured to asynchronously deliver the effective sub-conversation request set to the edge side queue and the cloud side queue based on the cross-layer scheduling instruction set, and perform cross-layer parallel processing on the sub-conversation requests in the effective sub-conversation request set based on the edge side queue and the cloud side queue.

8. A computer device comprising a memory and a processor, the memory storing a computer program, characterized in that, The processor executes the computer program to implement the steps of the method of any one of claims 1 to 6.

9. A computer readable storage medium having stored thereon a computer program, characterized in that, The computer program is executed by the processor to implement the steps of the method of any one of claims 1 to 6.

10. A computer program product comprising a computer program, characterized in that, The computer program is executed by the processor to implement the steps of the method of any one of claims 1 to 6.

Images