A multi-model cooperative processing method and system

Abstract

The application provides a multi-model cooperative processing method and system, and relates to the field of large language models. The method is executed by a local server and includes receiving a task input by a user; decomposing the task to obtain a plurality of subtasks; sending the plurality of subtasks to a remote server to process the plurality of subtasks by using a remote model deployed on the remote server; and receiving a plurality of subtask results corresponding to the plurality of subtasks returned by the remote server, and integrating the plurality of subtask results to generate an integrated result. The system includes a receiving module, a decomposition module, a processing module, and an integration module. The application can simultaneously improve the quality and efficiency of generating an integrated result.

Description

Technical Field

[0001] This specification relates to the field of large language models, and in particular to a multi-model collaborative processing method and system. Background Technology

[0002] Currently, artificial intelligence (AI) solutions on the market mainly fall into two categories: one is remote models deployed on remote servers, such as OpenAI's Generative Pre-trained Transformer (GPT). These remote models possess powerful reasoning capabilities and knowledge reserves, but rely on stable network connections, have high computational costs, and long response times; the other is local models deployed on local servers, which offer rapid response but limited functionality. Both types of solutions have their advantages and disadvantages, but neither can independently meet the complex needs of complex scenarios (e.g., construction scenarios).

[0003] Current research has attempted to employ hybrid architectures, such as using a local model to handle simple requests and a remote model to handle complex requests. However, these solutions typically classify requests based on simple rules or thresholds, failing to establish an intelligent collaboration mechanism between the local and remote models, and thus cannot effectively solve practical problems in complex scenarios.

[0004] Therefore, it is necessary to provide a multi-model collaborative processing method and system to simultaneously improve the quality and efficiency of generating integrated results. Summary of the Invention

[0005] To address the challenge of simultaneously improving the quality and efficiency of generating integrated results, this invention provides a multi-model collaborative processing method and system.

[0006] The invention includes a multi-model collaborative processing method executed by a local server. The method includes: receiving a task input by a user; decomposing the task into multiple subtasks; sending the multiple subtasks to a remote server to process the subtasks using remote models deployed on the remote server; and receiving the results of the multiple subtasks returned by the remote server, and integrating the results to generate an integrated result.

[0007] The invention includes a multi-model collaborative processing system. The system comprises: a receiving module configured to receive a task input by a user; a decomposition module configured to decompose the task into multiple subtasks; a processing module configured to send the multiple subtasks to a remote server for processing using a remote model deployed on the remote server; and an integration module configured to receive the results of the multiple subtasks returned by the remote server, integrate the results, and generate an integrated result.

[0008] The beneficial effects of the above invention include, but are not limited to: quickly decomposing a task into multiple simpler subtasks through a local server, sending multiple subtasks to a remote server to utilize a remote model deployed on the remote server to process the multiple subtasks, and then integrating and outputting the results of the multiple subtasks. This can establish an efficient collaboration mechanism between the local server and the remote model, enhance the processing capabilities of the remote model, and improve the quality and generation efficiency of the integrated results. Attached Figure Description

[0009] This specification will be further described by way of exemplary embodiments, which will be described in detail with reference to the accompanying drawings. These embodiments are not limiting; in these embodiments, the same reference numerals denote the same structures, wherein:

[0010] Figure 1 These are schematic diagrams illustrating application scenarios of a multi-model collaborative processing system according to some embodiments of this specification;

[0011] Figure 2 This is an exemplary block diagram of a multi-model collaborative processing system according to some embodiments of this specification;

[0012] Figure 3 This is an exemplary flowchart of a multi-model collaborative processing method according to some embodiments of this specification;

[0013] Figure 4 This is an exemplary flowchart of a task decomposition method according to some embodiments of this specification;

[0014] Figure 5 This is an exemplary flowchart illustrating a method for sending multiple subtasks according to some embodiments of this specification;

[0015] Figure 6 This is an exemplary flowchart illustrating a method for sending multiple subtasks according to some embodiments of this specification. Detailed Implementation

[0016] To more clearly illustrate the technical solutions of the embodiments in this specification, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are merely some examples or embodiments of this specification. For those skilled in the art, these drawings can be applied to other similar scenarios without creative effort. Unless obvious from the context or otherwise specified, the same reference numerals in the drawings represent the same structures or operations.

[0017] It should be understood that the terms “system,” “device,” “unit,” and / or “module” used herein are one way to distinguish different components, elements, parts, sections, or assemblies at different levels. However, if other terms can achieve the same purpose, they may be replaced by other expressions.

[0018] Unless the context clearly indicates an exception, words such as "a," "an," "a kind," and / or "the" do not specifically refer to the singular and may also include the plural. Generally speaking, the terms "comprising" and "including" only indicate the inclusion of explicitly identified steps and elements, which do not constitute an exclusive list, and the method or apparatus may also include other steps or elements.

[0019] Flowcharts are used in this specification to illustrate the operations performed by the system according to embodiments of this specification. It should be understood that the preceding or following operations are not necessarily performed in exact order. Instead, the steps can be processed in reverse order or simultaneously. Furthermore, other operations can be added to these processes, or one or more steps can be removed from them.

[0020] Taking construction scenarios as an example, in the current intelligent transformation of the construction industry, AI technology is being widely applied in various aspects such as project management, safety monitoring, and quality inspection. The collaborative application of local sensors and remote models has gradually become widespread. However, current AI applications in construction scenarios face the following technical challenges: 1. The contradiction between service quality and resource consumption. Construction sites typically require rapid decision-making, but high-quality AI judgment often relies on powerful remote models, leading to high latency and high resource consumption. While locally deployed models offer rapid response and low resource consumption, their accuracy and adaptability are limited, making them unable to handle complex and ever-changing construction problems. 2. Unstable network environment. Construction sites often have incomplete network coverage and unstable signal strength. Remote servers may become inaccessible due to network interruptions, causing the decision-making system to fail at critical moments, lacking an effective degradation mechanism. 3. Inefficient collaboration between local and remote systems: Existing systems have a crude collaboration mechanism between local and remote models, typically employing a simple binary strategy (i.e., local processing or remote processing), lacking intelligent task allocation and result integration mechanisms, and failing to effectively guide remote processing with preliminary local judgment results. 4. Unintelligent Prompt Construction: When sending requests to the remote model, prompts are often pre-set generic templates, failing to fully utilize the environmental information and preliminary judgment results already acquired by the remote model. This forces the remote model to process redundant information, reducing efficiency and increasing costs. This problem is particularly prominent in complex and ever-changing construction scenarios. For example, the complex and ever-changing construction site environment means that traditional fixed-structure prompts cannot adapt to different scenario requirements, leading to unstable response quality of the large model. Furthermore, the lack of semantic conversion mechanisms for construction-specific scenarios during information interaction between the local and remote models results in information loss. Additionally, existing prompt generation methods often use uniform templates, failing to fully consider the impact of environmental data on construction task execution, reducing the accuracy of professional guidance provided by the remote model. Moreover, multi-source heterogeneous data (images, sounds, vibrations, etc.) acquired remotely is difficult to effectively integrate into structured prompts, affecting the understanding and decision-making quality of the large model. 5. Inappropriate Resource Allocation: Using the same AI processing path for simple and complex tasks leads to resource waste or insufficient processing capacity, failing to dynamically adjust resource allocation according to the characteristics of the construction scenario.

[0021] To address the issues of low information interaction efficiency and unstable prompt quality between local and remote models, a context-sensitive prompt template dynamic generation system and method based on the "task decomposition and parallel processing" strategy is proposed. The aim is to establish an efficient collaboration mechanism between local and remote models, and to improve the overall decision-making quality and efficiency of the system by transforming the preliminary judgment results of the local model and environmental data into structured, high-quality prompt words.

[0022] This invention adopts a "smart decomposition, concurrent request, and dynamic integration" working mode. First, a local model deployed on a local server performs preliminary processing and task decomposition on the user-input task. Then, multiple structured, high-quality prompt words are generated for each decomposed subtask. These prompt words are then sent in parallel to a remote model for processing. Finally, an intelligent integration mechanism integrates the multiple return results into unified decision support information. The core innovations of this invention include: 1. Intelligent task decomposition and distribution mechanism. An innovative task decomposition algorithm based on construction business characteristics is proposed, decomposing complex construction decision requirements into multiple logically independent but interrelated subtasks, such as environmental assessment, risk identification, scheme generation, and specification verification. A processing graph is constructed based on task dependencies to achieve optimal parallel processing path design. This mechanism breaks through the traditional "single large model processing the complete task" mode, significantly improving system response speed and processing quality. 2. Multi-level parallel prompt template generation system. A dedicated prompt template library for different sub-core characteristics is designed, and parallel dynamic generation of prompt templates is implemented. Through multi-dimensional analysis of environmental characteristics, task types, and historical effects, the system can simultaneously construct highly customized prompts for multiple sub-tasks, effectively solving the problem that traditional prompts cannot meet the diverse needs of complex construction scenarios. 3. Asynchronous concurrent requests and dynamic scheduling mechanism. An intelligent concurrent request management system for remote models was developed, supporting batch asynchronous requests, dynamic priority adjustment, and automatic retry on failure. Dynamic scheduling of requests based on task urgency, dependencies, and network conditions was implemented, ensuring timely processing of critical tasks in construction environments with unstable network conditions and optimizing overall response time. 4. Semantic collaborative integration and conflict reconciliation algorithm. An innovative semantic collaborative integration algorithm for multi-source results was proposed, capable of identifying logical relationships, dependencies, and potential conflicts between results from different sub-tasks. Through techniques such as weighted voting, conflict detection and reconciliation, and contextual analysis, fragmented results returned by multiple large models are intelligently integrated into coherent and consistent decision information, solving the problems of result fragmentation and difficulty in handling conflicts under traditional methods. 5. Elastic degradation and progressive response mechanism. A resilient degradation strategy was designed to adapt to the complex network environment of construction sites. This strategy achieves a gradual response through task importance assessment and rapid return of partial results. When some remote requests fail, the system can provide initial decision support based on the returned results and local model capabilities, and dynamically update as more results are returned, ensuring continuous decision support under various network conditions.

[0023] This invention represents a leap from "single large-model processing" to "multi-model collaborative parallel processing," overcoming the limitations of traditional prompt words. While ensuring high-quality decision support, it significantly improves the system's response speed, robustness, and adaptability in complex construction environments. This invention is particularly suitable for scenarios such as construction sites where multiple dimensions of information (e.g., safety risks, technical specifications, environmental conditions, etc.) need to be considered simultaneously, and where network environments are unstable, providing a new technical path for intelligent construction decision-making.

[0024] Figure 1 This is a schematic diagram illustrating an application scenario of a multi-model collaborative processing system according to some embodiments of this specification. In some embodiments, the application scenario 100 of the multi-model collaborative processing system may include a local server 110, a remote server 120, a network 130, a storage device 140, and a user terminal 150.

[0025] In some embodiments, the application scenario 100 of the multi-model collaborative processing system can be applied to complex scenarios such as construction, industrial manufacturing, smart agriculture, urban emergency management, environmental monitoring, and logistics and warehousing management. For ease of description, the construction scenario will be used as an example below.

[0026] Local server 110 refers to a server deployed at the construction site. In some embodiments, local models can be deployed on local server 110. Local models are characterized by their small size, low resource consumption, and fast response. For example, local models may include Convolutional Neural Networks (CNN), Deep Neural Networks (DNN), and Recurrent Neural Networks (RNN).

[0027] In some embodiments, the local server 110 can be used to process data related to a multi-model collaborative processing system. For example, the local server 110 can receive user-input tasks. The local server 110 can decompose the tasks into multiple subtasks. The local server 110 can send the multiple subtasks to a remote server to process the multiple subtasks using remote models deployed on the remote server. The local server 110 can receive the results of the multiple subtasks returned by the remote server, integrate the results of the multiple subtasks, and generate an integrated result.

[0028] In some embodiments, the local server 110 may be a single server or a group of servers. The server group may be centralized or distributed.

[0029] Remote server 120 refers to a server deployed in the cloud. In some embodiments, remote models can be deployed on remote server 120. Remote models are characterized by their large size, high resource consumption, and slow response time. For example, remote models may include GPT, Large Language Model Meta AI (Llama), and DeepSeek, etc.

[0030] In some embodiments, the remote server 120 may receive multiple subtasks sent by the local server 110 and process the multiple subtasks using a remote model deployed on the remote server 120.

[0031] In some embodiments, the remote server 120 may be a single server or a group of servers. The server group may be centralized or distributed. In some embodiments, the remote server 120 may be implemented on a cloud platform. By way of example only, the cloud platform may include private cloud, public cloud, hybrid cloud, community cloud, distributed cloud, internal cloud, multi-tiered cloud, etc., or any combination thereof.

[0032] Network 130 may include any suitable wired or wireless network that facilitates the exchange of information and / or data. For example, local server 110 and remote server 120 may transmit information and / or data via the network.

[0033] Storage device 140 may store data, instructions, and / or any other information. In some embodiments, storage device 140 may store data and / or instructions related to the multi-model collaborative processing system. For example, storage device 140 may store user-inputted tasks. As another example, storage device 140 may store instructions for decomposing a task into multiple subtasks.

[0034] In some embodiments, storage device 140 may be connected to network 130 to communicate with one or more other components of application scenario 100 of the multi-model collaborative processing system (e.g., local server 110, remote server 120, network 130, and / or user terminal 150, etc.). One or more components of application scenario 100 of the multi-model collaborative processing system can access data or instructions stored in the storage device via the network. In some embodiments, each server (i.e., local server 110, remote server 120) has its own corresponding storage device.

[0035] In some embodiments, user terminal 150 may include mobile device 150-1, tablet computer 150-2, laptop computer 150-3, and virtual reality device 150-4, or any combination thereof. In some embodiments, local server 110 may be part of user terminal 150. In some embodiments, users can input tasks through user terminal 150 and query integrated results through user terminal 150.

[0036] It should be noted that the application scenarios are provided for illustrative purposes only and are not intended to limit the scope of the invention. Those skilled in the art will recognize that various modifications or variations can be made based on the description provided. For example, the application scenarios can be implemented on other devices to achieve similar or different functions. However, these variations and modifications will not depart from the scope of the invention.

[0037] Figure 2 This is an exemplary block diagram of a multi-model collaborative processing system 200 according to some embodiments of this specification. In some embodiments, the multi-model collaborative processing system 200 may include a receiving module 210, a decomposition module 220, a processing module 230, and an integration module 240. In some embodiments, the multi-model collaborative processing system 200 may also include a supplementary module 250.

[0038] The receiving module 210 is configured to receive user input tasks. More information about receiving tasks can be found in the description of step 310.

[0039] The decomposition module 220 is configured to decompose the task into multiple subtasks. More details on task decomposition can be found in the description of step 320.

[0040] Processing module 230 is configured to send multiple subtasks to a remote server to process the subtasks using a remote model deployed on the remote server. More details regarding sending subtasks can be found in the description of step 330.

[0041] The integration module 240 is configured to receive multiple subtask results corresponding to multiple subtasks returned by the remote server, integrate the multiple subtask results to generate an integrated result. More details regarding the integration of subtask results can be found in the description of step 340.

[0042] The supplementary module 250 can be configured to supplement the integration results based on the edge database and preset supplementary rules. For more information on supplementing the integration results, please refer to the relevant description in step 350.

[0043] It should be understood that Figure 2The system and its modules shown can be implemented in various ways. It should be noted that the above description of the multi-model collaborative processing system and its modules is for convenience only and should not limit the invention to the scope of the illustrated embodiments. It is understood that those skilled in the art, after understanding the principle of the system, may arbitrarily combine the modules or construct subsystems connected to other modules without departing from this principle. In some embodiments, Figure 2 The receiving module 210, decomposition module 220, processing module 230, integration module 240, and supplementary module 250 disclosed herein can be different modules within a single system, or a single module can implement the functions of two or more of the aforementioned modules. For example, the modules can share a single storage module, or each module can have its own separate storage module. Such variations are all within the scope of protection of this invention.

[0044] Figure 3 This is an exemplary flowchart of a multi-model collaborative processing method according to some embodiments of this specification. In some embodiments, such as Figure 3 As shown, the multi-model collaborative processing flow 300 may include steps 310-340. In some embodiments, such as Figure 3 As shown, the multi-model collaborative processing flow 300 may further include step 350. In some embodiments, Figure 3 One or more operations in the multi-model collaborative processing flow 300 shown can be performed in... Figure 1 The multi-model collaborative processing system shown is implemented in application scenario 100. For example, Figure 3 The multi-model collaborative processing flow 300 shown can be stored in the storage device 140 in the form of instructions and called and / or executed by the local server 110.

[0045] In some embodiments, the local server may receive a task input by the user; decompose the task into multiple subtasks; send the multiple subtasks to a remote server to process the multiple subtasks using a remote model deployed on the remote server; and receive the results of the multiple subtasks returned by the remote server, and integrate the results of the multiple subtasks to generate an integrated result. In some embodiments, the local server may also supplement the integrated result based on an edge database and preset supplementary rules.

[0046] Step 310: Receive task input from the user. In some embodiments, step 310 may be performed by the receiving module 210.

[0047] The user refers to the person who issues the task.

[0048] A task refers to a specific instruction or request that requires collaborative processing by multiple models. For example, a task can take, but is not limited to, the following forms: operation instructions, problem-solving, functional requirements, etc. In some embodiments, a task can involve data input in multiple modalities, including text, audio, images, and video. When the construction scenario is a complex construction scenario requiring visual understanding, the task can typically use images and / or video as the primary input form.

[0049] In some embodiments, users can input tasks through a multi-channel input interface on the user terminal using various input methods such as voice commands, text input, and image uploads. The multi-channel input interface of the user terminal refers to a set of input channels provided by the user terminal to receive user tasks, supporting multiple different interaction methods. The multi-channel input interface allows users to interact with the user terminal through multiple "channels" such as voice, text, gestures, touch, and vision, thereby improving the flexibility, naturalness, and efficiency of the interaction.

[0050] In some embodiments, the local server can receive user-inputted tasks from the user terminal via a network.

[0051] Step 320: Decompose the task into multiple subtasks. In some embodiments, step 320 may be performed by the decomposition module 220.

[0052] A subtask is a smaller task derived from a main task.

[0053] In some embodiments, a local server can use a local model to process tasks to obtain multiple subtasks. For example, the local server can input a task into a local model, which will then output multiple subtasks. A local model refers to a model deployed on a local server. More information about local models can be found at [link to relevant documentation]. Figure 1 And its corresponding description. The local server can use historical tasks as training data to train a local model, enabling the local model to output multiple sub-tasks based on the task. The labels corresponding to the training data can be manually input or... Figure 4 The method described is used to determine this.

[0054] In some embodiments, the local server may preprocess the tasks before decomposing them. Preprocessing includes outlier filtering, data standardization, and timestamp alignment.

[0055] In some embodiments, the local server can extract the core features of the task to determine the task's feature vector; select a decomposition strategy based on the feature vector; and decompose the task based on the decomposition strategy to obtain multiple subtasks. In some embodiments, the local server can also, for one of the multiple subtasks, determine whether the subtask needs further decomposition based on its complexity; and, in response to the complexity exceeding a complexity threshold, further decompose the subtask. For more information on task decomposition, please refer to [link to relevant documentation]. Figure 4 And its corresponding description.

[0056] Step 330 involves sending multiple subtasks to a remote server to process the subtasks using a remote model deployed on the remote server. In some embodiments, step 330 may be performed by processing module 230.

[0057] A remote model refers to a model deployed on a remote server. In some embodiments, there may be one remote model, and the local server can use the same remote model to process multiple subtasks. In other embodiments, there may be multiple remote models, and the local server can determine the target remote model suitable for each subtask and use the target remote model corresponding to each subtask to process that subtask. For more information on remote models, please refer to [link to relevant documentation]. Figure 1 and Figure 6 And its corresponding description.

[0058] In some embodiments, the local server can determine a task dependency graph based on the dependencies between multiple subtasks; determine the execution order of the multiple subtasks based on the task dependency graph; and send the multiple subtasks to a remote server based on the execution order, so as to utilize a remote model deployed on the remote server to process the multiple subtasks. For more information on sending and processing multiple subtasks, please refer to [link to relevant documentation]. Figure 5 And its corresponding description.

[0059] In some embodiments, the local server may, for one of multiple subtasks, obtain the sub-core features of the subtask; determine a template suitable for the subtask based on the sub-core features; determine a target remote model suitable for the subtask from multiple remote models based on the template; and send the subtask to the remote server for processing using the target remote model. For more information on sending and processing multiple subtasks, please refer to [link to relevant documentation]. Figure 6 And its corresponding description.

[0060] Step 340: Receive multiple subtask results corresponding to multiple subtasks returned by the remote server, and integrate the multiple subtask results to generate an integrated result. In some embodiments, step 340 can be performed by the integration module 240.

[0061] The subtask result refers to the result of the subtask after it has been processed by the remote model.

[0062] The integration result refers to the final result after integrating the results of multiple subtasks.

[0063] In some embodiments, the local server can receive the results of multiple subtasks corresponding to multiple subtasks returned by the remote server via a network.

[0064] In some embodiments, the local server can preprocess the received results of multiple subtasks to construct a request-response mapping table (e.g., recording in the mapping table that the response ID "R56789" corresponds to the request of subtask 2, containing rainfall impact analysis results), associating multiple subtask results with multiple subtasks to prepare for subsequent integration. For example, the local server can perform preprocessing such as format validation, parsing, and preliminary cleaning on the received results of multiple subtasks. Exemplarily, the local server can modify or validate the format to ensure that subsequent output is in a preset format, or to ensure consistency with the format of other related or dependent subtask results (e.g., if the local server detects that the return result of subtask 2 contains additional non-JSON formatted instructions, it automatically structures it into standard JSON format). The local server can concatenate the processing results of different subtasks while maintaining contextual coherence. For example, the local server can use conjunctions to maintain the logical order and fluency of statements to generate the integrated result.

[0065] In some embodiments, a response receiving buffer can be designed to asynchronously receive and temporarily store the subtask results returned by the remote server, and then integrate them after all the subtask results have been returned.

[0066] In some embodiments, the local server may integrate the results of the subtasks at the front end of the dependency relationship based on the dependencies between multiple subtasks, and then integrate the results of the subtasks at the back end of the dependency relationship.

[0067] A dependency relationship refers to the association between multiple subtasks, meaning that the execution of one subtask affects another. The result of a subtask at the front of the dependency relationship refers to the result of the subtask corresponding to the subtask at the front of the dependency relationship. The result of a subtask at the back of the dependency relationship refers to the result of the subtask corresponding to the subtask at the back of the dependency relationship. For example, if the processing of subtask B requires the result of subtask A, then subtask B depends on subtask A. In this dependency relationship, subtask A is the subtask at the front of the dependency relationship, and subtask B is the subtask at the back of the dependency relationship. For more information on dependencies, please refer to [link to relevant documentation]. Figure 5 And its corresponding description.

[0068] Understandably, a subtask can have dependencies on multiple other subtasks. For example, the processing of subtask B depends on the result of subtask A, and the processing of subtask C depends on the result of subtask B. In this case, subtask B is a subtask following subtask A and also a subtask preceding subtask C.

[0069] In some embodiments of this specification, the results of subtasks at the front end of the dependency relationship are integrated first, and then the results of subtasks at the back end of the dependency relationship are integrated. This ensures that the results of subtasks at the front end of the dependency relationship are integrated before the results of subtasks at the back end of the dependency relationship, thereby saving resources and improving accuracy.

[0070] In some embodiments, the local server can analyze the results of multiple subtasks to identify multiple conflicting subtask results; for each conflicting subtask result, determine the confidence level of the conflicting subtask result based on the reference basis corresponding to the conflicting subtask result; and integrate the multiple conflicting subtask results based on the confidence levels of the multiple conflicting subtask results.

[0071] Conflicting subtask results refer to the results of subtasks that have semantic conflicts.

[0072] In some embodiments, the local server can perform semantic consistency checks on the results of multiple subtasks to identify semantic conflicts between different subtask results, thereby determining the conflicting subtask results.

[0073] The cited sources for the conflict subtask results refer to the sources of information related to the content in the conflict subtask results. For example, cited sources may include national standards, industry guidelines, papers, patent documents, books, official websites, personal webpages, comprehensive analyses, etc. In some embodiments, each subtask result returned by the remote server will include its corresponding cited sources.

[0074] The confidence level of the conflict subtask results refers to the degree of credibility of the conflict subtask results.

[0075] In some embodiments, the local server can determine the confidence level based on a reference basis-confidence level lookup table (also known as a first data lookup table). For example, if the reference basis corresponding to the result of a conflicting subtask is a national standard, the confidence level corresponding to the national standard can be looked up in the first data lookup table and used as the confidence level of the conflicting subtask result. When multiple conflicting subtask results have multiple reference bases, the confidence level of the subtask can be determined based on their average confidence level.

[0076] In some embodiments, the local server can, based on the confidence levels of multiple conflicting subtask results, retain the core ideas of the high-confidence conflicting subtask results while using the low-confidence conflicting subtask results as supplementary references to perform preliminary integration of the multiple conflicting subtask results, and then integrate the preliminary integration result with other subtask results. Alternatively, the local server can only retain the conflicting subtask result with the highest confidence level and integrate it with the other subtask results.

[0077] In some embodiments, the local server can construct a cross-reference network among the subtask results to enhance the internal consistency and logical integrity of the fused results. This cross-reference network is used to enhance the relevance, logic, and integrity of information. For example, each subtask result may have its own reference basis, or multiple conflicting subtask results may share reference basis, thus enabling the establishment of a cross-reference network.

[0078] For example, the local server detected a conflict in the interpretation of safety restrictions for high-temperature construction in the results of subtask 1 and subtask 3: subtask 1 suggested adjusting work hours when the temperature exceeded 32℃, while subtask 3 cited a standard indicating 33℃ as the limit threshold. The local server identified this as a "data conflict." The local server analyzed the basis for the two temperature thresholds and found that subtask 1 was based on real-time environment and worker conditions, while subtask 3 was based on national standards. Based on the first data comparison table, the local server determined the confidence levels for the two subtasks to be: 0.85 for subtask 1 and 0.92 for subtask 3. The local server uses a conflict resolution strategy to handle temperature threshold conflicts. Since this falls under the category of "data conflict," the local server prioritizes the higher-confidence specification requirements (i.e., 33℃ is a hard limit), while also incorporating real-time situation analysis suggestions (i.e., the current temperature of 32.5℃ is close to the limit, and some workers are not adequately protected). The resulting comprehensive recommendation is: "According to specifications, 33℃ is the threshold for high-temperature construction, and the current temperature of 32.5℃ is close to this value. Considering the on-site worker protection and continuous working hours, it is recommended to implement an intermittent work system and enhance heatstroke prevention measures." In the final output, the local server found a lack of specific worker rotation schedules and added them through a knowledge supplementation mechanism: "In high-temperature environments, it is recommended that workers not work continuously for more than 1 hour, rest for at least 15 minutes, and replenish fluids and electrolytes." The final integrated result uses the overall concrete pouring process as the main thread, closely linking safety risk points, specification requirements, and curing measures through cross-referencing.

[0079] In some embodiments, the local server may integrate the results of multiple conflict subtasks based on the conflict type and the confidence level of the results of multiple conflict subtasks.

[0080] Conflict type refers to the kind of conflict between the results of multiple conflict subtasks. For example, conflict categories can include factual conflicts, opinion conflicts, data conflicts, and solution conflicts.

[0081] In some embodiments, for different conflict types, the local server can integrate the results of multiple conflict subtasks in different ways based on the conflict type and the confidence level of the results of multiple conflict subtasks. For example, for factual conflicts, the local server can implement a weighted voting mechanism based on confidence level.

[0082] In some embodiments of this specification, integrating conflict results based on confidence levels can improve accuracy. Further consideration of conflict types when integrating results from multiple conflict subtasks can further improve accuracy.

[0083] In some embodiments, for conflicting viewpoints, the local server can retain multiple perspectives and identify the different sources. In some embodiments, for data conflicts, the local server can employ outlier detection and statistical methods to filter the most reliable data. In some embodiments, for conflicting solutions, the local server can construct a matrix comparing the advantages and disadvantages of different solutions to support user decision-making.

[0084] In some embodiments, the local server can determine the importance of multiple subtasks based on their sub-core features; determine important and minor subtasks based on the importance of the multiple subtasks; in response to receiving the subtask result corresponding to the important subtask, use the subtask result corresponding to the important subtask as a first integration result and output the first integration result; in response to receiving the subtask result corresponding to the minor subtask, retain the subtask result corresponding to the minor subtask until all subtask results corresponding to the minor subtask are received, then integrate all subtask results corresponding to the minor subtask to determine a second integration result and output the second integration result.

[0085] Sub-core features refer to the key attributes used to describe sub-tasks. For more information on sub-core features, please refer to [link to relevant documentation]. Figure 5 And its corresponding description.

[0086] Importance refers to a numerical value or letter that reflects the weight of a subtask in the overall task. For example, importance can be represented by a numerical value between 1 and 10, the letter 'af', or a star rating. The higher the value, the higher the lexicographical ranking, or the higher the star rating, the greater the importance.

[0087] In some embodiments, the local server may determine the importance based on a sub-core feature-importance lookup table (also known as a second data lookup table).

[0088] Important subtasks are those with a higher impact weight; minor subtasks are those with a lower impact weight. In some embodiments, the local server can identify subtasks with an importance greater than an importance threshold as important subtasks, and subtasks with an importance no greater than the importance threshold as minor subtasks. The importance threshold can be preset.

[0089] In some embodiments, in response to receiving the subtask result corresponding to an important subtask, the local server can use the subtask result corresponding to the important subtask as the first integration result and output the first integration result. For example, if subtask 1 (security risk assessment) is an important subtask, after the result is returned, the local server immediately extracts the key security risk points and sends them to the user terminal for display, marking them as "preliminary results, in full analysis and processing", so that the user can take emergency security measures first.

[0090] In some embodiments, in response to receiving the subtask result corresponding to the minor subtask, the local server may retain the subtask result corresponding to the minor subtask in the response receiving buffer until all the subtask results corresponding to the minor subtask are received, then integrate all the subtask results corresponding to the minor subtask to determine the second integration result and output the second integration result.

[0091] In some embodiments of this specification, the results of important subtasks are output separately first, while the results of minor subtasks are received and integrated after all subtask results are received, which is more user-friendly and more suitable for emergency situations.

[0092] Step 350: Supplement the integration result based on the edge database and preset supplementary rules. In some embodiments, step 350 may be performed by the supplementation module 250.

[0093] An edge database refers to a database deployed at the construction site or a cloud-based database adapted to the construction scenario, which stores known knowledge related to the construction scenario (such as construction specifications, user manuals, etc.). For example, an edge database may store: when the temperature is between 30℃ and 33℃, the specific work shift schedule for construction personnel is: "In high-temperature environments, it is recommended that workers work continuously for no more than 1 hour, rest for no less than 15 minutes, and replenish water and electrolytes."

[0094] Pre-defined supplementary rules refer to pre-set supplementary rules that define the supplementary conditions and corresponding supplementary content. For example, pre-defined supplementary rules may include: in high-temperature environments, specific arrangements for construction personnel rotation schedules need to be supplemented.

[0095] In some embodiments, the local server can determine whether the supplementation conditions are met based on preset supplementation rules; if they are met, it queries the client-side database based on the content to be supplemented, determines the corresponding supplementation content, and supplements the integration result. For example, if the local server finds that the integration result needs to be supplemented with specific construction personnel rotation schedules, it adds the following after querying the client-side database: "In high-temperature environments, it is recommended that workers work continuously for no more than 1 hour, rest for no less than 15 minutes, and replenish water and electrolytes."

[0096] In some embodiments of this specification, when information gaps or deficiencies are found in the integration results, they are supplemented using the edge database and preset supplementation rules, thereby improving accuracy.

[0097] In some embodiments of this specification, a task is quickly decomposed into multiple simpler subtasks by a local server, and these subtasks are sent to a remote server to be processed by a remote model deployed on the remote server. The results of the multiple subtasks are then integrated and output, which can establish an efficient collaboration mechanism between the local server and the remote model, enhance the processing capabilities of the remote model, and improve the quality and efficiency of the integrated results.

[0098] It should be noted that the above description of the multi-model collaborative processing flow is merely for illustration and explanation, and does not limit the scope of the invention. Those skilled in the art can make various modifications and changes to the multi-model collaborative processing flow under the guidance of this invention. However, these modifications and changes are still within the scope of this invention.

[0099] In some embodiments, the local server can use domain-adaptive learning methods to achieve knowledge transfer of prompt templates from one type of construction scenario to another, reducing the workload of building a new scenario template library and improving the applicability of the multi-model collaborative processing system. After multiple iterations, a multi-model collaborative processing system can be applied to multiple scenarios.

[0100] In some embodiments, the local server can generate metadata for each task. This metadata includes information such as task identification (ID), priority, timeout settings, and retry policies. The task identification is a unique code for the task. For example, the task identification can be an identity marker, composed of letters, numbers, symbols, etc. The timeout setting refers to the condition that if a subtask is sent but exceeds a preset time threshold, the request is considered timed out. After a request times out, the request can be stopped or retried. The retry policy can include the number of retry attempts. For more information on priority, please refer to [link to relevant documentation]. Figure 5 And its corresponding description.

[0101] In some embodiments, the local server may design a result integrity check algorithm to verify whether all required subtask results have been received or are partially available.

[0102] In some embodiments, the local server can construct a semantic dependency model to determine that subtask 4 (maintenance plan) needs to integrate the temperature impact analysis of subtask 1 (high temperature risk) and the humidity change prediction of subtask 2 (rainfall impact). The local server can check the dependencies required by subtask 4 to confirm that it has received the complete subtask results of subtask 1 and 80% of the subtask results of subtask 2, which is sufficient to begin partial processing. The local server can identify that the results of subtask 3 (specification check) reference a specific temperature threshold (33℃) as a key judgment point, which is related to the temperature risk assessment in subtask 1 (32.5℃ is the high-risk starting point). The local server can construct an integration priority queue: first process the subtask results of subtasks 1 and 2, then process the specification check results of subtask 3, and finally process subtask 4, which depends on the former.

[0103] In some embodiments, the local server can present the integration results to the user and collect user feedback for continuous system optimization. For example, the local server can perform system optimization through steps S1-S13.

[0104] Step S1: The local server can monitor the status of the multi-model collaborative processing system in real time, including key indicators such as network connection quality, request success rate, and response latency. This includes real-time monitoring of the status of the multi-model collaborative processing system (including the connection between the local server and the remote server).

[0105] Step S2: The local server can design a multi-level system status classification standard, defining multiple intermediate states from "completely normal" to "severely restricted".

[0106] Step S3: The local server can implement an adaptive threshold mechanism, dynamically adjusting the status evaluation threshold based on historical performance data. By automatically adjusting the threshold according to historical performance data, a system state is determined when a certain threshold requirement is met.

[0107] Step S4: The local server can build a state transition prediction model to predict short-term changes in the system state based on the current trend and prepare response strategies in advance. For example, when the predicted system state changes from "completely normal" to "severely restricted", subtasks with long response times can be downgraded to avoid the long output time of subtasks with long response times, which would result in a long overall output time.

[0108] Step S5: The local server can design a preliminary response synthesis mechanism based on key subtasks, which generates a preliminary response immediately after obtaining the results of the most important subtasks.

[0109] Step S6: The local server can implement response content version management, and gradually update and enrich the response content as more subtask results are returned.

[0110] Step S7: The local server can develop a content difference marking system to clearly identify newly added, changed, and corrected content in the update response, thereby improving the user experience.

[0111] Step S8: The local server can introduce a response completeness indicator to display the percentage of the current response as a complete result.

[0112] Step S9: The local server can design a tiered degradation strategy library, and preset multi-level degradation schemes for different system states and fault types.

[0113] Step S10: The local server can implement an intelligent degradation decision engine to select the optimal degradation path based on the current system status, the status of completed subtasks, and the importance of the tasks.

[0114] Step S11: The local server can develop an end-side capability activation mechanism to maximize the use of the local model's local processing capabilities when remote requests are restricted.

[0115] Step S12: The local server can establish a human-machine collaboration enhancement loop to guide users to provide additional information or simplify their needs when the system's capabilities are severely limited, thereby assisting the system in completing the task.

[0116] Step S13: The local server can design a result update mechanism after service recovery, which will automatically complete the processing results after the network or service is restored, and identify the differences from the degradation results.

[0117] Figure 4 This is an exemplary flowchart of a task decomposition method according to some embodiments of this specification. In some embodiments, such as Figure 4 As shown, the task decomposition process 400 may include steps 410-430. In some embodiments, such as Figure 4 As shown, the task decomposition process 400 may further include step 440. In some embodiments, Figure 4 One or more operations in the task decomposition process 400 shown can be performed in... Figure 1 The multi-model collaborative processing system shown is implemented in application scenario 100. For example, Figure 4 The task decomposition process 400 shown can be stored in the storage device 140 as instructions and invoked and / or executed by the local server 110. In some embodiments, steps 410-440 can be executed by the decomposition module 420.

[0118] In some embodiments, the local server may determine the task's influencing factors and feature vector based on data related to the core features of the task, wherein the core features include at least one of the task's type, complexity, and urgency; select a decomposition strategy based on the feature vector; and decompose the task into multiple subtasks based on the decomposition strategy. In some embodiments, the local server may also determine the complexity of one of the multiple subtasks; determine whether the subtask needs to be further decomposed based on the complexity; and, in response to determining that the subtask needs to be further decomposed, further decompose the subtask.

[0119] Step 410: Based on the relevant data of the core features of the task, determine the task influence factor, and determine the feature vector of the task based on the task influence factor.

[0120] Core features refer to the key attributes used to describe a task. For example, core features may include at least one of the following: task type, complexity, and urgency. Alternatively, core features may include at least one of the following dimensions: required expertise, expected output, etc. Task type refers to the specific type of task. For example, task type may include safety assessment, solution design, and specification verification. Complexity refers to a numerical or alphabetical representation of the task's level of complexity. For example, complexity can be represented by a numerical value between 1 and 10, the letter 'af', or a star rating; a higher value, a higher lexicographical ranking, or a higher star rating indicates greater complexity. Urgency refers to a numerical or alphabetical representation of the task's level of urgency. For example, urgency can be represented by a numerical value between 1 and 10, the letter 'af', or a star rating; a higher value, a higher lexicographical ranking, or a higher star rating indicates greater urgency.

[0121] Data related to core features includes the values ​​of the core features and / or the parameters on which the calculation of the core features is based (i.e., parameters that affect the core features). For example, data related to core features includes values ​​for task type, computational complexity, and urgency, and the parameters on which these parameters are based.

[0122] In some embodiments, the local server can perform keyword matching on the user-input tasks, or map the user-input tasks to keywords to extract the core features of the tasks. For example, the local server can classify tasks by domain (e.g., security management, quality control, etc.), task form (e.g., information query, status assessment, etc.), time attribute, and interaction mode. As another example, the local server can construct a task complexity evaluation matrix to quantify task complexity from dimensions such as the number of information dimensions, the number of constraints, the breadth of professional knowledge, and the scope of decision impact. As yet another example, the local server can design a sub-task complexity evaluation model to quantify scores from dimensions such as computational complexity, knowledge coverage, data dependency, and decision difficulty to determine the complexity of sub-tasks. Furthermore, the local server can use an urgency scoring algorithm to calculate the urgency of tasks based on time sensitivity, security relevance, schedule dependency, and resource contention.

[0123] For example, a construction site manager inputs via a mobile device: "Today, we need to pour concrete for the 12th floor slab. The on-site temperature is 32°C, and there is expected to be showers in the afternoon. Please assess the construction safety risks, check whether the pouring plan complies with the specifications, and provide suggestions for concrete curing in high-temperature weather." The local server can collect environmental data (e.g., images showing the location and status of the mixer truck, temperature 32.5°C, humidity 68%, and 80% probability of rainfall after 3 hours). The local server can identify the core characteristics of the task, including task type, complexity, and urgency. For example, the local server can directly extract "concrete pouring" as a keyword from the user input, mapping "on-site temperature 32°C" and "concrete pouring" to the keyword "high-temperature construction." Task types include: (1) Domain classification: safety assessment; (2) Task form: specification compliance check; (3) Task form: technical solution suggestion. For another example, the local server can construct a task complexity assessment matrix, based on information dimensions (environmental data: location and orientation, temperature, humidity, weather conditions, etc.) and constraints (12th floor slab concrete pouring), with a computational complexity of 0.78. For example, the local server can use an urgency scoring algorithm to calculate an urgency of 0.85 based on time sensitivity (pouring construction time, expected rainfall time, etc.), safety correlation (safety of construction during rainfall, safety of construction during high temperatures, etc.), schedule dependence (current pouring progress, etc.) and resource contention (other input tasks of the user, input tasks of other users, etc.).

[0124] In some embodiments, the local server may also receive environmental data collected by local sensors; and, based on the environmental data, correct the core features.

[0125] Local sensors refer to sensors deployed at the construction site. For example, local sensors may include cameras, thermometers, hygrometers, anemometers, etc.

[0126] Environmental data refers to data that reflects the environment of the construction site. For example, environmental data can include visual data (on-site images, video streams), environmental parameters (temperature, humidity, wind speed, etc.), equipment status, location data, and weather forecasts. Specifically, the local server can acquire visual data such as images and video streams from cameras at the construction site; it can acquire temperature, humidity, and wind speed data from thermometers, hygrometers, and anemometers; it can acquire equipment status data from equipment detection devices; it can determine the location data of the construction site using positioning devices; and it can obtain weather forecasts for the construction site from databases or the internet.

[0127] In some embodiments, the local server can modify core features based on environmental data. For example, the local server can combine weather forecasts to modify the level of urgency, complexity, etc. For instance, if the weather forecast indicates a rainstorm warning in 2 hours and the task is expected to take 3 hours to complete, the level of urgency can be increased.

[0128] In some embodiments of this specification, the accuracy of core features can be improved by modifying them based on environmental data.

[0129] Task impact factors refer to factors that affect the conduct of a task, including safety, civil engineering, materials, and weather. Task impact factors can be determined based on the values ​​of core features and / or the parameters upon which those core features depend. For example, a local server can determine the task impact factor "safety" based on the task type, which includes "safety assessment"; when assessing complexity, factors such as "temperature, humidity, weather conditions," and "12-story concrete pouring" can be considered, thus determining the task impact factors "weather," "civil engineering," and "materials"; when assessing urgency, factors such as "construction time, rainfall time, and construction safety" can be considered, thus determining the task impact factors "civil engineering," "weather," and "safety." A total of five task impact factors are determined from these three points.

[0130] A feature vector is a vector that reflects the degree of influence of task influencing factors on a task. For example, each vector value in the feature vector corresponds to a task influencing factor, representing the degree of influence between the factor and the task. Continuing the example above, we can determine the vector values ​​corresponding to each task influencing factor, resulting in [0.9, 0.7, 0.6, 0.8, 0]. This indicates that the vector value for civil engineering (0.9) has the greatest impact on the task; safety (0.8) has the second greatest impact; materials (0.7) has the third greatest impact; meteorology (0.6) has the fourth greatest impact; and the others have a vector value of 0, indicating the least impact. The local server can determine the vector values ​​of each task influencing factor in the feature vector based on the correlation between each factor and the task description.

[0131] In some embodiments, the local server can analyze the professional fields and knowledge scope involved in the task based on a construction domain knowledge graph, determine the task influencing factors, and form a feature vector. For example, the local server can construct a multi-level construction domain knowledge graph and, based on a task-knowledge mapping algorithm, map the user-input task and environmental data to relevant nodes in the knowledge graph, thereby forming a high-dimensional feature vector. The construction domain knowledge graph can include a concept layer, a specification layer, a relation layer, and an instance layer. These layers can refer to different classification layers. The concept layer can point to concepts of different terms, the specification layer can point to different construction specifications, the relation layer can point to the association of different factors (e.g., factors related to construction under high temperatures), and the instance layer can point to specific examples (e.g., the specific content of pouring concrete under high temperatures). The high-dimensional feature vector includes dimensions such as task type encoding, complexity score, urgency index, professional field distribution, knowledge dependency degree, and environmental data characteristics.

[0132] For example, a local server can map tasks to nodes such as "concrete engineering" and "high-temperature construction" in a construction domain knowledge graph, generating feature vectors containing a professional domain distribution [0.9, 0.7, 0.6, 0.8, 0]. These nodes can then be used to determine other related features. For instance, based on "high-temperature construction," features such as "weather" and "safety" can be determined.

[0133] Step 420: Select a decomposition strategy based on the feature vector.

[0134] Decomposition strategy refers to the logical basis for breaking down a task. For example, decomposition strategies can include: professional dimension decomposition: decomposing tasks according to professional fields such as civil engineering, mechanical and electrical engineering, and decoration; process stage decomposition: decomposing tasks according to stages such as construction preparation, implementation, and acceptance; and functional module decomposition: decomposing tasks according to functional modules such as information extraction, specification inspection, scheme generation, and risk assessment. Different decomposition strategies can correspond to different task decomposition algorithms.

[0135] In some embodiments, the local server can use the decomposition strategy corresponding to the most frequently occurring influence factor type among the influence factor types corresponding to the feature vector as the decomposition strategy. For example, the feature vector includes five task influence factors: civil engineering, materials, meteorology, safety, and others. Among them, the influence factor type corresponding to "civil engineering" is "profession"; the influence factor type corresponding to "materials" is "function, profession, process"; the influence factor type corresponding to "meteorology" is "function"; the influence factor type corresponding to "safety" is "function"; and the influence factor type corresponding to "others" is "function, profession, process". "Function" appears 4 times, including four task influence factors "materials, meteorology, safety, and others"; "profession" appears 3 times, including three task influence factors "civil engineering, materials, and others"; and "process" appears 2 times, including two task influence factors "materials and others". Since the most frequently occurring influence factor type is "function", the most suitable decomposition strategy is functional module decomposition.

[0136] The impact factor type refers to the category to which each task's impact factor in the feature vector belongs. For example, impact factor types can include function, specialty, and process. There is a one-to-one correspondence between impact factor types and decomposition strategies; that is, the impact factor type "specialty" corresponds to the decomposition strategy "specialty dimension decomposition," the impact factor type "process" corresponds to the decomposition strategy "process stage decomposition," and the impact factor type "function" corresponds to the decomposition strategy "functional module decomposition."

[0137] In some embodiments, since core features, historical success rates, and resource status change in real time with the application of multi-model collaborative processing methods, the local server can establish a strategy selection evaluation function to calculate the applicability scores corresponding to various decomposition strategies based on the matching degree between core features and strategy applicability conditions, historical success rates, and resource status. Furthermore, the local server can automatically select a decomposition strategy in real time based on preset conditions and applicability scores.

[0138] For any given decomposition strategy among multiple strategies, the matching degree between the core features and the strategy's applicability conditions can be determined based on the overlap between the task-related influencing factors of the feature vector and the applicability conditions of the decomposition strategy. The applicability conditions of the strategy refer to the feature vector most suitable for that decomposition strategy, and can be pre-defined. Higher overlap results in a higher matching degree. Historical success rate refers to the success rate of returning results after decomposing data using this strategy and sending it to a remote model for processing in historical data. Resource status refers to the computational resources consumed by the decomposition strategy. The local server can assign an applicability score based on a lookup table (i.e., a third data lookup table) that compares the matching degree between core features and the strategy's applicability conditions, the historical success rate, and the resource consumption. Higher matching degree between core features and the strategy's applicability conditions, higher historical success rate, and lower resource consumption result in higher applicability and a higher applicability score.

[0139] Preset conditions refer to the conditions that a decomposition strategy must meet in advance. For example, the selection condition could be to choose the strategy with the highest applicability score as the decomposition strategy. Another example is to choose the strategy that meets the matching degree threshold, the historical success rate threshold, and the least resource consumption as the decomposition strategy.

[0140] For example, if the applicability scores for the professional dimension decomposition, process stage decomposition, and functional module decomposition determined by the local server are 0.82, 0.65, and 0.91 respectively, then the functional module decomposition corresponding to the highest score of 0.91 is selected as the decomposition strategy.

[0141] In some embodiments, the local server can determine the confidence value of the impact factor type corresponding to the feature vector based on the feature vector; and select the decomposition strategy corresponding to the impact factor type with the highest confidence value.

[0142] Confidence value refers to the overall reliability of the influencing factor types.

[0143] In some embodiments, for one of multiple impact factor types, the local server can combine multiple confidence values ​​corresponding to that impact factor type based on the vector values ​​of the task impact factors to determine the confidence value of that impact factor type. For example, the feature vector is: [0.9, 0.7, 0.6, 0.8, 0] (Civil Engineering, Materials, Meteorology, Safety, Others). The vector value of the impact factor type "Specialty" in Civil Engineering is 0.9; the vector value of the impact factor type "Function, Specialty, Process" in Materials is 0.7; the vector value of the impact factor type "Function" in Meteorology is 0.6; the vector value of the impact factor type "Function" in Safety is 0.8; and the vector value of the other impact factor types "Function, Specialty, Process" is 0. Then the confidence value of the impact factor type "Specialty" is 0.9 + 0.7 + 0 = 1.6; the confidence value of the impact factor type "Function" is 0.7 + 0.6 + 0.8 + 0 = 2.1; and the confidence value of the impact factor type "Process" is 0.7 + 0 = 0.7.

[0144] In some embodiments, the local server may use the decomposition strategy corresponding to the influence factor type with the highest confidence value as the decomposition strategy. For example, if the influence factor type "Function" has the highest confidence value, then the decomposition strategy "Functional Module Decomposition" corresponding to "Function" may be selected as the decomposition strategy.

[0145] In some embodiments of this specification, by determining the confidence value of the influence factor type corresponding to the feature vector, and then selecting the decomposition strategy corresponding to the influence factor type with the highest confidence value, the obtained decomposition strategy can be made more accurate and reliable.

[0146] Step 430: Based on the decomposition strategy, the task is decomposed into multiple subtasks.

[0147] In some embodiments, the local server can decompose a task based on a decomposition strategy to obtain multiple sub-tasks. For example, when the decomposition strategy is professional dimension decomposition, the local server can decompose the task according to professional fields; when the decomposition strategy is process stage decomposition, the local server can decompose the task according to stages; when the decomposition strategy is functional module decomposition, the local server can decompose the task according to functional modules. For example, when the decomposition strategy is determined to be "functional module decomposition", the user-input task "Today, 12 floors of concrete slab need to be poured. The on-site temperature is 32°C, and showers are expected in the afternoon. Please assess the construction safety risks, check whether the pouring plan complies with the specifications, and provide suggestions for concrete curing under high temperature weather" can be decomposed into 5 sub-tasks: "High Temperature Environment Safety Risk Assessment", "Rainfall Impact Analysis", "Pouring Plan Specification Compliance Check", "High Temperature Environment Curing Plan Generation", and "Quality Control Point Identification".

[0148] Step 440: For one of the multiple subtasks, determine whether to further decompose the subtask. In some embodiments, step 440 includes steps 441-443.

[0149] Step 441: Determine the complexity of the subtask.

[0150] Complexity refers to a numerical or alphabetical representation that reflects the complexity of a subtask. For example, complexity can be represented by a numerical value between 1 and 10, the letter 'af', or a star rating. The higher the value, the larger the lexicographical order, or the higher the star rating, the greater the complexity.

[0151] The method for determining the complexity of subtasks is similar to the method for determining the complexity of tasks described above, and will not be repeated here.

[0152] Step 442: Based on the complexity, determine whether the subtask needs to be further decomposed.

[0153] In some embodiments, the local server can determine whether the complexity exceeds a complexity threshold to determine whether the subtask needs further decomposition. If the complexity exceeds the threshold, the subtask needs further decomposition; if the complexity is not greater than the threshold, the subtask does not need further decomposition. The complexity threshold can be set manually or derived from historical data. For example, the local server can calculate the complexity of five subtasks as [0.62, 0.58, 0.71, 0.65, 0.60], with a complexity threshold of 0.5. Since the complexity of all five subtasks exceeds the threshold, further decomposition is unnecessary.

[0154] Step 443: In response to the determination that the subtask needs to be further decomposed, the subtask is further decomposed.

[0155] In some embodiments, in response to a complexity level exceeding a complexity threshold, the local server may further decompose the subtask. The process of further decomposing the subtask is similar to the process of decomposing the task, as described above.

[0156] In some embodiments of this specification, by decoupling tasks into simpler subtasks, the resource consumption of subtasks can be reduced, different subtasks can quickly point to the corresponding remote model, multiple subtasks can be processed simultaneously, and the processing speed of the remote model can be improved, thereby improving the decision-making quality and efficiency of the overall system.

[0157] In some embodiments, the local server can establish a parameter consistency check mechanism across subtasks to ensure that parameters such as environment descriptions and constraints used in different subtasks remain consistent.

[0158] In some embodiments, the local server can assess the complexity and resource requirements of each subtask to determine whether further decomposition is needed. For example, the local server can first determine the complexity of the subtasks, then establish a resource requirement mapping table to allocate estimated computational resources, network resources, time resources, and knowledge resource requirements for different types of subtasks, thereby implementing a recursive decoupling decision algorithm to determine whether further decomposition is needed based on the complexity score, estimated processing time, and resource requirements.

[0159] Figure 5 This is an exemplary flowchart illustrating a method for sending multiple subtasks according to some embodiments of this specification. In some embodiments, such as Figure 5 As shown, the multiple subtask sending process 500 may include steps 510-530. In some embodiments, Figure 5 The multiple subtask sending process shown in 500 can be one or more operations that can be performed in the process. Figure 1 The multi-model collaborative processing system shown is implemented in application scenario 100. For example, Figure 5 The multiple subtask sending processes 500 shown can be stored in the storage device 140 as instructions and invoked and / or executed by the local server 110. In some embodiments, steps 510-530 can be executed by the processing module 440.

[0160] In some embodiments, the local server may determine a task dependency graph based on the dependencies between multiple subtasks; determine the execution order of the multiple subtasks based on the task dependency graph; and send the multiple subtasks to a remote server based on the execution order, so as to process the multiple subtasks using a remote model deployed on the remote server.

[0161] Step 510: Determine the task dependency graph based on the dependencies between multiple subtasks.

[0162] A dependency relationship refers to the association between multiple subtasks. For more information on dependencies, please refer to [link to relevant documentation]. Figure 3 And its corresponding description.

[0163] In some embodiments, dependencies may include informational dependencies and logical relationships. For example, if the result of subtask A is a necessary condition for executing subtask B, then the informational dependency is that subtask B depends on subtask A, and the logical relationship is A→B.

[0164] In some embodiments, the local server can determine dependencies based on a data dependency analysis model, which can be a machine learning model. For example, the local server can input subtasks into the data dependency analysis model, and the model can output dependencies. The local server can use historical subtasks as training data to train the data dependency analysis model, enabling it to output the corresponding dependencies based on the subtasks. The labels for the training data can be manually input.

[0165] A task dependency graph is a graph that can reflect the relationships between multiple subtasks.

[0166] In some embodiments, the local server can use multiple subtasks as nodes in a task dependency graph and the dependencies between multiple subtasks as directed edges to determine the task dependency graph.

[0167] In some embodiments, the local server may also introduce dependency strength weights to quantify the tightness of dependencies (e.g., full dependency, partial dependency, or result validation dependency).

[0168] Step 520: Determine the execution order of multiple subtasks based on the task dependency graph.

[0169] The execution order refers to the order in which multiple subtasks are sent to the remote server.

[0170] In some embodiments, the local server may divide multiple subtasks into parallel subtask groups and serial subtask groups based on a task dependency graph; and determine the execution order based on the parallel subtask groups and serial subtask groups, wherein subtasks in the parallel subtask groups are executed simultaneously, and subtasks in the serial subtask groups are executed sequentially.

[0171] In some embodiments, the local server can identify, based on the task dependency graph, that subtask 4 is completely dependent on the subtask results of subtask 1 and subtask 2, subtask 5 is partially dependent on the subtask results of subtask 3, and subtask 1, subtask 2, and subtask 3 can be executed in parallel. In this case, "subtask 1 and subtask 2 → subtask 4" is a serial subtask group; "subtask 3 → subtask 5" is a serial subtask group; and "subtask 1, subtask 2, and subtask 3" is a parallel subtask group.

[0172] In this context, Subtask 4's complete dependence on the results of Subtasks 1 and 2 means that after the results of Subtask 1 (high-temperature environment safety risk assessment) and Subtask 2 (rainfall impact analysis) are determined, Subtask 4 (generating a high-temperature environment maintenance plan) depends on the results of the aforementioned two subtasks to determine its own results. Subtask 4, along with the results of Subtasks 1 and 2, is sent as input to the remote model, which then outputs the results of Subtask 4.

[0173] Subtask 5 (quality control point identification) partially relies on Subtask 3 (construction scheme specification compliance check). This means that while the results of Subtask 5 can be roughly derived, they still require further refinement based on the results of Subtask 3. For example, the results of Subtask 5 might include a wide range of quality control points. Based on the results of Subtask 3, the results of Subtask 5 can be refined into specific quality control points during the construction process. The results of Subtask 3 can be sent along with Subtask 5 as input to a remote model to obtain the precise results of Subtask 5.

[0174] In some embodiments, the local server can determine the execution order based on parallel subtask groups and serial subtask groups. For example, "Subtask 1 → Subtask 4" and "Subtask 3 → Subtask 5" are serial subtask groups; "Subtask 1, Subtask 2, and Subtask 3" are parallel subtask groups. The local server can determine the execution order as follows: First, subtasks 1, 2, and 3 are sent in parallel to their respective remote models, and their respective subtask results are obtained. Second, subtask 4, the subtask results of subtask 1, and the subtask results of subtask 2 are sent to the remote model, and the subtask result of subtask 4 is obtained. Third, subtask 5 and the subtask results of subtask 3 are sent to the remote model, and the subtask result of subtask 5 is obtained. The subtask results from subtask 1 to subtask 5 are then used as the final output. Alternatively, since there are no common subtasks between the serial task groups "Subtask 1 → Subtask 4" and "Subtask 3 → Subtask 5," the second and third steps can be performed simultaneously, or the third step can be performed first, followed by the second step. Alternatively, the order of the second and third steps can be determined based on the return times of the results of subtasks 1 and 3.

[0175] In some embodiments of this specification, parallel subtask groups and serial subtask groups are determined based on the task dependency graph, and then the execution order is determined. Subtasks in the parallel subtask group can be sent simultaneously to improve efficiency, while subtasks in the serial subtask group can be executed sequentially to improve the accuracy of the integration result.

[0176] In some embodiments, the local server may determine the priority of multiple subtasks based on the task dependency graph and the sub-core characteristics of multiple subtasks; and determine the execution order of multiple subtasks based on the priority of multiple subtasks.

[0177] Sub-core features refer to the key attributes used to describe sub-tasks. For example, sub-core features may include at least one of the sub-task's task type, complexity, and urgency. The acquisition method for sub-core features is similar to that for core features, as described above. It should be noted that a single core feature of a task may be broken down into different sub-tasks simultaneously.

[0178] Priority refers to the order in which subtasks are sent to the remote server. For example, priorities can be level 1, level 2, level 3, etc.

[0179] In some embodiments, the local server can determine the priority of multiple subtasks based on dependencies in the task dependency graph (the more subtasks that depend on a subtask, the higher the priority of that subtask) and the complexity (higher complexity, higher priority) and urgency (higher urgency, higher priority) of the sub-core features of multiple subtasks. For example, the local server determines the priority based on a dependency-complexity-urgency-priority lookup table (also known as a fourth data lookup table). The more subtasks that depend on a subtask, and the higher their complexity and urgency, the higher their priority.

[0180] In some embodiments, the local server can determine the execution order of multiple subtasks based on their priorities. For example, subtask 1 has a priority level of 1, subtask 3 has a priority level of 2, subtask 2 has a priority level of 3, subtask 4 has a priority level of 4, and subtask 5 has a priority level of 5. The local server can then determine the execution order as follows: subtask 1, subtask 3, subtask 2, subtask 4, and subtask 5 are sent sequentially to their respective remote models.

[0181] In some embodiments of this specification, the execution order of multiple subtasks is determined based on their priorities, and subtasks with higher priorities can be sent first, while subtasks with lower priorities can be sent later.

[0182] In some embodiments, the local server can monitor the processing status information of multiple subtasks in real time; adjust the priority of multiple subtasks in real time based on the processing status information; and determine the execution order of multiple subtasks based on the adjusted priority of multiple subtasks.

[0183] In some embodiments, the local server can determine the execution order of multiple subtasks based on the task dependency graph by executing steps S1-S3.

[0184] Step S1: Monitor the processing status information of multiple subtasks in real time.

[0185] Processing status information refers to information that reflects the processing status of a subtask. For example, processing status information can include processing, processing completed, processing failed, waiting, etc. For example, a local server can add all subtask requests to a dynamic request pool and display their status in real time: Subtask 1 (processing, 15 seconds), Subtask 2 (processing, 12 seconds), Subtask 3 (waiting), Subtask 4 (waiting), Subtask 5 (queued).

[0186] In some embodiments, the local server can monitor the processing status information of multiple subtasks in real time.

[0187] Step S2: Based on the processing status information, adjust the priority of multiple subtasks in real time.

[0188] In some embodiments, the processing status information includes response time. For one of multiple subtasks, if the response time is greater than a first time threshold, the local server can increase the priority of the subtask. The first time threshold is a pre-set value for determining whether to increase the priority of a subtask. For example, if a subtask has a priority level of 5 and its response time is greater than the first time threshold, the local server can increase the priority of the subtask to level 4.

[0189] In some embodiments of this specification, subtasks with excessively long response times can have their priority increased and their resource allocation increased to prevent them from being unable to execute.

[0190] In some embodiments, during execution, when the response time exceeds a first time threshold, the local server may also automatically increase its network bandwidth allocation and adjust the start time of subtasks that depend on the subtask.

[0191] In some embodiments, for one of a plurality of subtasks, when the response time exceeds a second time threshold, the local server may resend the subtask to the remote server. The second time threshold is greater than a first time threshold. Furthermore, in response to a resend count exceeding a certain threshold, the priority of the subtask is reduced. The second time threshold is a pre-set value for determining whether to resend the subtask to the remote server. The second time threshold is greater than the first time threshold.

[0192] In some embodiments of this specification, when the response time exceeds a second time threshold, the subtask is considered to have failed, and the subtask is resent to the remote server for reprocessing. When the number of resends exceeds a threshold, the local server can lower its priority to avoid prolonged resource consumption.

[0193] Step S3: Determine the execution order of the multiple subtasks based on their adjusted priorities.

[0194] The process of determining the execution order of multiple subtasks based on their adjusted priorities is similar to the process of determining the execution order of multiple subtasks based on their priorities, as described above.

[0195] In some embodiments of this specification, by adjusting the priorities of multiple subtasks in real time, the execution order of multiple subtasks can be determined in real time, thereby dynamically adjusting the processing priority of subtasks to improve resource utilization efficiency.

[0196] Step 530: Send multiple subtasks to a remote server based on the execution order, so as to use the remote model deployed on the remote server to process the multiple subtasks.

[0197] The process of sending multiple subtasks to a remote server based on the execution order, so as to utilize the remote model deployed on the remote server to process the multiple subtasks, is similar to the process in step 330. Please refer to the above and its corresponding description.

[0198] In some embodiments of this specification, a task dependency graph is determined based on the dependencies between multiple subtasks, thereby determining the execution order, which can improve the accuracy and efficiency of the integration results.

[0199] It should be noted that the above description of the multiple subtask sending process is merely for illustration and explanation, and does not limit the scope of the invention. Those skilled in the art can make various modifications and changes to the multiple subtask sending process under the guidance of this invention. However, these modifications and changes are still within the scope of this invention.

[0200] In some embodiments, the local server may construct a semantic dependency model between subtask results based on the task dependency graph, in order to integrate the results of multiple subtasks to generate an integrated result.

[0201] In some embodiments, the local server can first integrate multiple subtasks within a serial subtask group, then integrate the serial subtask groups themselves, and finally perform global optimization. For example, "Subtask 1 and Subtask 2 → Subtask 4" and "Subtask 3 → Subtask 5" are serial subtask groups. Integrating Subtask 1, Subtask 2, and Subtask 4 generates integration result 1, and integrating Subtask 3 and Subtask 5 generates integration result 2. The local server can then integrate integration results 1 and 2 and finally perform global optimization.

[0202] In some embodiments, the local server can monitor the status of all concurrent requests in real time and collect performance metrics such as response time and success rate. Furthermore, a response receiving buffer is designed to asynchronously receive and temporarily store the return results from the remote model. For example, the results of completed subtasks are stored in the response receiving buffer, and further processing is performed only after all subtask results have been returned. For subtasks in a sequential subtask group, when the results of later subtasks have returned but the results of earlier subtasks have not, the results of later subtasks can be stored in the response receiving buffer.

[0203] For example, the local server can record the processing status information of multiple subtasks: subtask 1 (response time 28 seconds, success), subtask 2 (response time 22 seconds, success). The local server receives the subtask results of subtask 1 and subtask 2 and stores them in the response buffer, notifying subtask 4 that its dependent data is partially ready.

[0204] Figure 6 This is an exemplary flowchart illustrating a method for sending multiple subtasks according to some embodiments of this specification. In some embodiments, such as Figure 6 As shown, the multiple subtask sending process 600 may include steps 610-640. In some embodiments, Figure 6 One or more operations of the multiple subtask sending process 600 shown can be performed in... Figure 1 The multi-model collaborative processing system shown is implemented in application scenario 100. For example, Figure 6 The multiple subtask sending processes 600 shown can be stored in the storage device 140 as instructions and invoked and / or executed by the local server 110. In some embodiments, steps 610-640 can be executed by the processing module 440.

[0205] In some embodiments, for one of a plurality of subtasks, the local server may obtain the subcore features of the subtask; determine a template that is compatible with the subtask based on the subcore features; determine a target remote model that is compatible with the subtask from a plurality of remote models based on the template; and send the subtask to the remote server to process the subtask using the target remote model.

[0206] Step 610: Obtain the sub-core features of the subtask.

[0207] Sub-core features refer to the key attributes used to describe sub-tasks. For example, sub-core features may include dimensions such as task type, required expertise, and expected output. Task type can correspond to a function, required expertise to a profession, and expected output corresponds to user input. For example, if the user input is "Today, we need to pour concrete for the 12th floor slab. The on-site temperature is 32℃, and showers are expected this afternoon. Please assess the construction safety risks, check whether the pouring plan complies with specifications, and provide suggestions for concrete curing in high-temperature weather," the corresponding expected output could include the risk level and specific risk points, and concrete curing suggestions.

[0208] For more information on sub-core features, please refer to [link / reference]. Figure 5 And its corresponding description.

[0209] Step 620: Based on the sub-core features, determine the template that is compatible with the sub-task.

[0210] A template adapted to a subtask refers to a template that summarizes the main content of the subtask. For example, a template could be: Current Temperature (), Humidity (), Continuous Working Time (), Job Type (), and Task Type (). Parentheses "()" indicate template parameters that need to be added. More information about template parameters can be found below and in their corresponding descriptions.

[0211] In some embodiments, the local server can pre-set high-quality templates for different types of sub-tasks (such as safety inspections, construction plan evaluations, and material selection) to form a template library. The local server can determine templates suitable for sub-tasks based on sub-core features using a template matching model. The template matching model is a machine learning model. For example, the local server can input sub-core features into the template matching model, which will then output templates suitable for the sub-tasks. The local server can use historical sub-core features as training data to train the template matching model, enabling it to output corresponding templates suitable for the sub-tasks based on the sub-core features. The labels corresponding to the training data can be manually input.

[0212] In some embodiments, the local server can determine the front-end subtask that has a dependency relationship with the subtask; based on the sub-core features and the template corresponding to the front-end subtask, determine the template that is adapted to the subtask, and the output format of the template adapted to the subtask is the same as the output format of the template corresponding to the front-end subtask.

[0213] In some embodiments, the local server can determine the front-end subtasks that have dependencies on the subtasks based on the task dependency graph. Based on the sub-core features, a template adapted to the subtask is determined, and it is ensured that the output format of the template adapted to the subtask is the same as the output format of the template corresponding to the front-end subtask.

[0214] In some embodiments of this specification, the output format of the template adapted to the subtask is the same as the output format of the template corresponding to the preceding subtask. This ensures that the output formats of interdependent subtasks are identical, facilitating subsequent result fusion. For example, the output format of the template adapted to the subtask and the output format of the template corresponding to the preceding subtask are both text.

[0215] Step 630: Based on the template, determine the target remote model that is compatible with the subtask from multiple remote models.

[0216] The target remote model refers to the remote model that is most suitable for the subtask.

[0217] In some embodiments, the local server can assign the most suitable target remote model to each subtask based on a pre-configured model-remote model mapping table. The model-remote capability mapping table is preset and can be updated manually or automatically periodically. Each template is mapped to a corresponding remote model. For example, subtask 1 (security risk assessment) is assigned a large security domain optimization model, and subtask 3 (standard compliance check) is assigned a large professional building model.

[0218] Step 640: Send the subtask to the remote server so that the target remote model can process the subtask.

[0219] In some embodiments, the local server may determine the template parameters of the template based on the sub-core features; determine the prompt words of the template based on the template parameters, the prompt words including at least one of the relevant parameters of the sub-task and the result requirements of the sub-task; and send the sub-task and the prompt words to the remote server.

[0220] Template parameters refer to the data that needs to be added to the template. For example, in the current temperature (32.5℃), humidity (68%), continuous working time (estimated 6 hours), job type (concrete pouring), and task type (safety assessment), the data in parentheses are template parameters.

[0221] In some embodiments, for one of a plurality of subtasks, the local server may determine the sub-core features based on environmental data and the preliminary analysis results of the local server (e.g., the preliminary analysis results of the local model); determine the template based on the template matching results; and determine the template parameters based on the sub-core features and the selected template.

[0222] In some embodiments, the local server may determine the initial template parameters of the template based on the sub-core features; determine the front-end sub-task that has a dependency relationship with the sub-task; and adjust the initial template parameters based on the template parameters of the front-end sub-task's template to determine the template parameters of the template.

[0223] Initial template parameters refer to the template parameters determined based on the sub-core features.

[0224] When the template parameters of the current subtask template are changed, the local server can automatically recognize and update the template parameters.

[0225] In some embodiments, the local server can also automatically adjust parameter configurations based on feedback from the effects of similar historical subtasks.

[0226] For example, the local server fills the template for subtask 1 with the following key parameters: current temperature (32.5℃), humidity (68%), estimated working time (6 hours), and job type (concrete pouring). When subtask 2 obtains an update from the meteorological data application interface, increasing the probability of rainfall from 80% to 90%, the local server automatically propagates this change to subtask 4 (curing plan), updating its "rainfall preparation" parameter section. The local server retrieves historical records and optimizes the weights of the water-cement ratio and slump parameters in the subtask 3 (specification check) template. Simultaneously, the local server detects a difference in temperature parameters used by subtask 1 and subtask 3 (32.5℃ and 32℃), automatically unifying them to the sensor-measured value of 32.5℃ to ensure consistent evaluation.

[0227] In some embodiments of this specification, based on the core features of the sub-task and the template corresponding to the front-end sub-task, a template adapted to the sub-task is determined. This can maintain parameter consistency, improve the accuracy of the processing results, and facilitate subsequent result integration.

[0228] A prompt is a summary of the content corresponding to the template. For example, a prompt may include at least one of the following: relevant parameters of the subtask and the subtask result requirements. The relevant parameters of the subtask describe the parameters of the subtask, while the subtask result requirements specify the required output of the subtask.

[0229] In some embodiments, the local server can determine the prompt words of the template based on template parameters. For example, the local server can explicitly include the position and role of the subtask in the overall task in the prompt words. Another example is that the local server can apply a prompt word quality assessment algorithm to automatically evaluate and optimize the generated prompt words, including dimensions such as completeness, clarity, and structure. Yet another example is that the local server can embed result tags and formatting instructions in the prompt words to facilitate subsequent automatic parsing and fusion of the results returned by the large model.

[0230] For example, the local server can generate the following prompt for subtask 1: "Analyze the safety risks of pouring concrete for a 12-story floor slab in an environment with a temperature of 32.5℃ and humidity of 68%. Worker availability is: [Image recognition results]. Provide a risk level assessment and specific risk points." The local server can add contextual information to the prompt for subtask 4: "This is a subtask about generating a concrete pouring and curing plan under high-temperature conditions. Your output will be combined with the safety risk assessment and rainfall impact analysis results." The local server can evaluate the prompt for subtask 3 and automatically supplement it with: "Please specifically refer to the clauses regarding high-temperature construction in the 'Code for Construction of Concrete Structures' GB50666." The local server can add formatting requirements to the prompt for subtask 2: "Please return the results in the following format: 1. Impact level [low / medium / high]; 2. Impact list [JSON]; 3. Recommended measures [point-by-point explanation]."

[0231] In some embodiments, the local server can send subtasks and prompts to a remote server over a network.

[0232] In some embodiments, the local server may adjust the prompt word based on the network status between the local server and the remote server; and send the subtask and the adjusted prompt word to the remote server.

[0233] Network status refers to parameters that reflect whether the network between a local server and a remote server is functioning properly. For example, network status may include bandwidth values.

[0234] In some embodiments, the local server can dynamically adjust the detail and length of the prompt words based on the network status between the local server and the remote server, and prioritize the retention of key information when bandwidth is limited.

[0235] In some embodiments, the local server can adjust the prompt words based on the network status and response time prediction between the local server and the remote server. The response time prediction needs to be determined by combining the subtask and the corresponding remote model. For example, the more complex the subtask and the lower the computational power of the remote model, the longer the predicted response time will be.

[0236] For example, when bandwidth decreases in the network state between the local server and the remote server, the local server can reduce the number of subtasks sent. For instance, the local server can postpone sending subtask 5 to ensure network resources for critical subtasks 1-3.

[0237] In some embodiments, the local server can send subtasks and modified prompts to a remote server over a network.

[0238] In some embodiments of this specification, adjusting the prompt words based on the network status between the local server and the remote server can prevent network congestion and prioritize the retention of critical information when bandwidth is limited.

[0239] In some embodiments of this specification, assigning appropriate prompts to each subtask can improve the processing efficiency of the remote model for the subtask.

[0240] In some embodiments, the local server can send multiple subtasks corresponding to the same target remote model to the remote server in batches.

[0241] Multiple subtasks corresponding to the same target remote model have similar and independent logic. Sending these multiple subtasks to the remote server in batches can reduce the number of network interactions. For example, subtask 1 and subtask 2 have similar logic (both are risk assessments) and correspond to the same target remote model. The local server can combine them into a single batch processing request, sharing the environment description part, reducing the request load by 40%.

[0242] In some embodiments of this specification, sending multiple subtasks corresponding to the same target remote model to a remote server in batches can improve processing efficiency.

[0243] In some embodiments of this specification, for one of a plurality of subtasks, the processing performance of the remote model on the subtask is improved by determining a target remote model that is compatible with the subtask.

[0244] It should be noted that the above description of the multiple subtask sending process is merely for illustration and explanation, and does not limit the scope of the invention. Those skilled in the art can make various modifications and changes to the multiple subtask sending process under the guidance of this invention. However, these modifications and changes are still within the scope of this invention.

[0245] In some embodiments, the local server may design a request preflight mechanism to check the quality, length, and compliance of the prompt words before sending, ensuring the request is valid. Based on the corresponding target remote model, the requirements for the prompt words corresponding to the target remote model are determined, thereby checking the prompt words of the subtasks sent to the target remote model to ensure the request is valid.

[0246] In some embodiments, the local server pre-detection finds that the prompt words for subtask 4 exceed the model token limit, and can automatically compress and reconstruct them. The local server generates request metadata for subtask 1: {taskID:“ST12345-1”, priority:“high”, timeout:30s, retry_strategy:“immediate”, max_retries:3}.

[0247] In some embodiments, for large-scale construction projects, the local server can be designed with a distributed architecture, with multiple local servers working together to generate prompts and integrate environmental data from different locations and angles to form a more comprehensive scene description.

[0248] In some embodiments, the local server can incorporate modeling of the construction personnel's professional background and operating habits to achieve personalized adaptation of prompt templates to different users, thereby improving the matching degree between prompt words and users' cognitive patterns.

[0249] In some embodiments, when network bandwidth decreases, the local server can compress the prompts for subtasks while retaining the core questions.

[0250] The basic concepts have been described above. Obviously, for those skilled in the art, the detailed disclosure above is merely illustrative and does not constitute a limitation of this specification. Although not explicitly stated herein, those skilled in the art may make various modifications, improvements, and corrections to this specification. Such modifications, improvements, and corrections are suggested in this specification and therefore remain within the spirit and scope of the exemplary embodiments described herein.

[0251] Furthermore, this specification uses specific terms to describe embodiments thereof. For example, "an embodiment," "one embodiment," and / or "some embodiments" refer to a particular feature, structure, or characteristic associated with at least one embodiment of this specification. Therefore, it should be emphasized and noted that references to "an embodiment," "one embodiment," or "an alternative embodiment" in different locations throughout this specification do not necessarily refer to the same embodiment. Moreover, certain features, structures, or characteristics in one or more embodiments of this specification can be appropriately combined.

[0252] Furthermore, unless expressly stated in the claims, the order of processing elements and sequences, the use of numbers and letters, or other names described in this specification are not intended to limit the order of the processes and methods described herein. Although various examples have been discussed in the foregoing disclosure of some embodiments of the invention that are currently considered useful, it should be understood that such details are for illustrative purposes only, and the appended claims are not limited to the disclosed embodiments; rather, the claims are intended to cover all modifications and equivalent combinations that conform to the spirit and scope of the embodiments described herein. For example, while the system components described above can be implemented using hardware devices, they can also be implemented solely using software solutions, such as installing the described system on existing servers or mobile devices.

[0253] Similarly, it should be noted that, in order to simplify the description disclosed herein and thus aid in the understanding of one or more embodiments of the invention, the foregoing description of embodiments in this specification may sometimes combine multiple features into a single embodiment, drawing, or description thereof. However, this method of disclosure does not imply that the subject matter of this specification requires more features than those mentioned in the claims. In fact, the embodiments contain fewer features than all the features of a single embodiment disclosed above.

[0254] In some embodiments, numbers describing the quantity of components and attributes are used. It should be understood that such numbers used in the description of embodiments are modified in some examples with the terms "approximately," "approximately," or "generally." Unless otherwise stated, "approximately," "approximately," or "generally" indicates that the numbers are allowed to vary by ±20%. Accordingly, in some embodiments, the numerical parameters used in the specification and claims are approximate values, which may be changed depending on the characteristics required by individual embodiments. In some embodiments, numerical parameters should take into account specified significant digits and employ a general method of digit reservation. Although the numerical ranges and parameters used to confirm their breadth of range in some embodiments of this specification are approximate values, in specific embodiments, such values ​​are set as precisely as feasible.

[0255] For each patent, patent application, patent application publication, and other material such as articles, books, specifications, publications, and documents referenced in this specification, the entire contents of which are incorporated herein by reference. This excludes historical application documents that are inconsistent with or conflict with the content of this specification, as well as documents that limit the broadest scope of the claims in this specification (currently or subsequently appended to this specification). It should be noted that in the event of any inconsistency or conflict between the descriptions, definitions, and / or terminology used in the supplementary materials to this specification and the content of this specification, the descriptions, definitions, and / or terminology used in this specification shall prevail.

[0256] Finally, it should be understood that the embodiments described in this specification are merely illustrative of the principles of the embodiments described herein. Other variations may also fall within the scope of this specification. Therefore, alternative configurations of the embodiments described herein are intended to be illustrative rather than limiting, and should be considered consistent with the teachings of this specification. Accordingly, the embodiments described herein are not limited to those explicitly introduced and described herein.

Claims

1. A multi-model collaborative processing method, executed by a local server located at a construction site, characterized in that, include: The task of receiving user input; Receive environmental data from the construction site and correct the core features of the task based on the environmental data; The task is decomposed based on the revised core features to obtain multiple sub-tasks; For each of the subtasks, determine the subcore features of the subtask; Based on the aforementioned core features, determine a template and its parameters that are compatible with the sub-task; Based on the template parameters, the prompt words of the template are determined, and the prompt words include at least one of the relevant parameters of the subtask and the result requirements of the subtask; The multiple subtasks and their corresponding prompts are sent to a remote server so that the multiple subtasks can be processed using a remote model deployed on the remote server. The remote model includes at least one of GPT, large language model meta AI, and DeepSeek. as well as, Receive the results of the multiple subtasks corresponding to the multiple subtasks returned by the remote server, and integrate the results of the multiple subtasks to generate an integrated result; The step of determining the template and its parameters that are adapted to the sub-task based on the sub-core features includes: Based on the sub-core features, the initial template parameters of the template are determined; Identify the preceding subtasks that have a dependency on the subtask; and, Based on the template parameters of the template of the front-end sub-task, the initial template parameters are adjusted to determine the template parameters of the template.

2. The method according to claim 1, characterized in that, The task is decomposed into multiple sub-tasks, including: Based on the data related to the corrected core features, the task impact factor and the feature vector of the task are determined. The core features include at least one of the task type, complexity, and urgency of the task. Based on the aforementioned feature vectors, a decomposition strategy is selected; and, Based on the decomposition strategy, the task is decomposed to obtain the multiple subtasks.

3. The method according to claim 1, characterized in that, The process of decomposing the task into multiple sub-tasks also includes: For one of the multiple subtasks Determine the complexity of the subtask; Based on the stated complexity, determine whether the subtask needs further decomposition; and... In response to determining that the subtask needs to be further decomposed, the subtask is further decomposed.

4. The method according to claim 1, characterized in that, The step of sending the multiple subtasks and their corresponding prompts to a remote server, so as to utilize a remote model deployed on the remote server to process the multiple subtasks, includes: Based on the dependencies between the multiple subtasks, a task dependency graph is determined; Based on the task dependency graph, the execution order of the plurality of sub-tasks is determined; and, Based on the execution order, the multiple subtasks and their corresponding prompts are sent to the remote server so that the remote model deployed on the remote server can be used to process the multiple subtasks.

5. The method according to claim 4, characterized in that, Determining the execution order of the multiple sub-tasks based on the task dependency graph includes: Based on the task dependency graph, the multiple subtasks are divided into parallel subtask groups and serial subtask groups; and, The execution order is determined based on the parallel subtask group and the serial subtask group, wherein the subtasks in the parallel subtask group are executed simultaneously, and the subtasks in the serial subtask group are executed sequentially.

6. The method according to claim 4, characterized in that, Determining the execution order of the multiple sub-tasks based on the task dependency graph includes: Based on the task dependency graph and the sub-core features of the multiple subtasks, the priority of the multiple subtasks is determined, wherein the sub-core features include at least one of the complexity and urgency of the subtasks; and, The execution order of the multiple subtasks is determined based on their priorities.

7. The method according to claim 6, characterized in that, Determining the execution order of the multiple sub-tasks based on the task dependency graph includes: Real-time monitoring of the processing status information of the multiple subtasks; Based on the processing status information, the priorities of the multiple subtasks are adjusted in real time; and, The execution order of the multiple subtasks is determined based on their adjusted priorities.

8. The method according to claim 7, characterized in that, The processing status information includes response time, and the real-time adjustment of the priorities of the multiple sub-tasks based on the processing status information includes: For one of the multiple subtasks, if the response time is greater than a first time threshold, the priority of the subtask is increased.

9. The method according to claim 8, characterized in that, The method further includes: For one of the multiple subtasks When the response time exceeds a second time threshold, the subtask is resent to the remote server, where the second time threshold is greater than the first time threshold; and... When the number of retransmissions exceeds a threshold, the priority of the subtask is reduced.

10. The method according to claim 1, characterized in that, The remote model includes multiple sub-tasks. Sending the multiple sub-tasks and their corresponding prompts to a remote server, so that the remote model deployed on the remote server can process the multiple sub-tasks, includes: Based on the template, a target remote model adapted to the subtask is determined from multiple remote models; and, The subtask and the corresponding prompt word are sent to the remote server so that the target remote model can process the subtask.

11. The method according to claim 1, characterized in that, Sending the subtask and the corresponding prompt word to the remote server further includes: Adjust the prompt words based on the network status between the local server and the remote server; and The subtask and the adjusted prompt are sent to the remote server.

12. The method according to claim 1, characterized in that, Sending the multiple subtasks and their corresponding prompts to the remote server includes: Multiple sub-tasks corresponding to the same target remote model and their corresponding prompt words are sent in batches to the remote server.

13. The method according to claim 1, characterized in that, The step of receiving the results of multiple subtasks corresponding to the multiple subtasks returned by the remote server, and integrating the results of the multiple subtasks to generate an integrated result includes: Based on the core features of the multiple sub-tasks, the importance of the multiple sub-tasks is determined; Based on the importance of the multiple subtasks, important subtasks and secondary subtasks are determined; In response to receiving the subtask result corresponding to the important subtask, the subtask result corresponding to the important subtask is used as the first integration result, and the first integration result is output; and, In response to receiving the subtask result corresponding to the secondary subtask, the subtask result corresponding to the secondary subtask is retained until all the subtask results corresponding to the secondary subtask are received. Then, the subtask results corresponding to all the secondary subtasks are integrated to determine the second integration result and output the second integration result.

14. The method according to claim 1, characterized in that, The integration of the results of the multiple subtasks includes: Based on the dependencies between the multiple subtasks, the results of the subtasks at the front end of the dependency relationship are first integrated, and then the results of the subtasks at the back end of the dependency relationship are integrated.

15. The method according to claim 1, characterized in that, The integration of the results of the multiple subtasks includes: Analyze the results of the multiple subtasks to identify multiple conflicting subtask results; For each conflicting subtask result, the confidence level of the conflicting subtask result is determined based on the citation basis corresponding to the conflicting subtask result; and, Based on the confidence level of the results of the multiple conflict subtasks, the results of the multiple conflict subtasks are integrated.

16. The method according to claim 15, characterized in that, The integration of the results of the multiple conflict subtasks based on their confidence levels includes: The results of the multiple conflict subtasks are integrated based on the conflict type and the confidence level of the results of the multiple conflict subtasks.

17. The method according to claim 1, characterized in that, The method further includes: The integration results are supplemented based on the edge database and preset supplementary rules.

18. A multi-model collaborative processing system, characterized in that, include: The receiving module is configured to receive user-input tasks and environmental data from the construction site. The decomposition module is configured to correct the core features of the task based on the environmental data, and decompose the task based on the corrected core features to obtain multiple sub-tasks; The processing module is configured to: for each of the subtasks, determine the sub-core features of the subtask; Based on the aforementioned core features, determine a template and its parameters that are compatible with the sub-task; Based on the template parameters, the prompt words of the template are determined, and the prompt words include at least one of the relevant parameters of the subtask and the result requirements of the subtask; and the multiple subtasks and the corresponding prompt words are sent to a remote server to process the multiple subtasks using a remote model deployed on the remote server, and the remote model includes at least one of GPT, large language model meta AI and DeepSeek; as well as, The integration module is configured to receive the results of multiple subtasks corresponding to the multiple subtasks returned by the remote server, and integrate the results of the multiple subtasks to generate an integration result; The step of determining the template and its parameters that are adapted to the sub-task based on the sub-core features includes: Based on the sub-core features, the initial template parameters of the template are determined; Identify the preceding subtasks that have a dependency on the subtask; and, Based on the template parameters of the template of the front-end sub-task, the initial template parameters are adjusted to determine the template parameters of the template.

Images