Query report determination method and device, storage medium and electronic equipment

Abstract

The application discloses a query report determination method and device, a storage medium and an electronic equipment, relates to the technical field of artificial intelligence, and comprises the following steps: receiving a query request input by a target object through multiple input modes, and collecting a current query record of the target object, wherein the multiple input modes include a voice input mode, a document input mode and a picture input mode; determining a query task corresponding to the target object according to multiple query requests and the current query record; decomposing the query task into multiple logical subtasks, and distributing the multiple logical subtasks to corresponding query agents respectively; and determining a query report corresponding to the query task according to query results of the multiple query agents. The technical problem that the generated content of an existing search enhancement generation application is inaccurate is solved, and the technical effect of improving the generation accuracy of query results is achieved.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, and in particular to a method and apparatus for determining query reports, a storage medium, and an electronic device. Background Technology

[0002] In recent years, artificial intelligence technologies, represented by Large Language Models (LLMs), have demonstrated enormous potential in the medical field, such as applying AI to medical literature summarization, medical record generation, and doctor-patient dialogue assistance. However, directly applying general-purpose LLMs to high-risk, high-precision clinical decision support scenarios still faces significant challenges. Their inherent knowledge cutoff means the model cannot access the latest clinical guidelines, drug information, or cutting-edge research findings; simultaneously, the "hallucination" problem is unacceptable in the medical field, as any fabricated treatment recommendation or drug dosage could potentially trigger serious safety incidents.

[0003] Therefore, Retrieval-Augmented Generation (RAG) technology has been introduced into the medical field. Medical RAG systems retrieve relevant text fragments from a specific medical knowledge base and provide them to the LLM (Low-Level Modeler) before generating a response. This method alleviates the model illusion problem to some extent. However, these traditional medical RAG systems lack the ability to comprehensively analyze and plan for complex clinical problems. The heterogeneity and silos of medical knowledge sources lead to low retrieval efficiency, causing RAG systems to fail to generate accurate solutions when dealing with clinical problems.

[0004] This shows that there is a problem with the accuracy of search results generated by search enhancement applications in related technologies. Summary of the Invention

[0005] This application provides a method and apparatus for determining query reports, a storage medium, and an electronic device to at least address the problem that search results generated by search enhancement applications are not accurate enough in related technologies.

[0006] This application provides a method for determining a query report, comprising: receiving query requests input by a target object through multiple input methods, and collecting the current query records of the target object, wherein the multiple input methods include: voice input, document input, and image input; determining a query task corresponding to the target object based on the multiple query requests and the current query records; decomposing the query task into multiple logical subtasks, and assigning the multiple logical subtasks to corresponding query agents; and determining a query report corresponding to the query task based on the query results of the multiple query agents.

[0007] This application also provides a device for determining a query report, comprising: an information receiving module, configured to receive query requests input by a target object through multiple input methods, and to collect the current query records of the target object, wherein the multiple input methods include: voice input, document input, and image input; a task determining module, configured to determine a query task corresponding to the target object based on the multiple query requests and the current query records; a task decomposition module, configured to decompose the query task into multiple logical subtasks and assign the multiple logical subtasks to corresponding query agents; and a report determining module, configured to determine a query report corresponding to the query task based on the query results of the multiple query agents.

[0008] This application also provides an electronic device, comprising: a memory for storing a computer program; and a processor for executing the computer program to implement the steps of any of the above-described query report determination methods.

[0009] This application also provides a computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, it implements the steps of any of the above-described query report determination methods.

[0010] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described query report determination methods.

[0011] This application utilizes intent analysis based on the input of voice, documents, images, and currently viewed content from the target object to determine the target object's query task. Then, based on the query task's implementation logic, the query task is decomposed into multiple logical sub-tasks, which are then assigned to corresponding query agents for processing. Finally, a query report corresponding to the query task is generated based on the query results from each query agent. This solves the technical problem of inaccurate content generation in existing search enhancement applications, achieving the technical effect of improving the accuracy of generated query results. Attached Figure Description

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

[0013] Figure 1 This is a schematic diagram illustrating an application scenario of a method for determining a query report according to an embodiment of this application;

[0014] Figure 2This is a flowchart illustrating an optional method for determining a query report according to an embodiment of this application;

[0015] Figure 3 This is a schematic diagram of an optional search enhancement generation system according to an embodiment of this application;

[0016] Figure 4 This is a structural block diagram of an optional query report determination device according to an embodiment of this application. Detailed Implementation

[0017] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0018] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0019] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0020] According to one aspect of the embodiments of this application, a method for determining a query report is provided. Optionally, in this embodiment, the above-described method for determining a query report may be applied, but is not limited to, to applications such as... Figure 1 The hardware environment shown includes terminal device 102 and server 104. Server 104 can be connected to terminal device 102 via a network and can be used to provide services (e.g., application services, etc.) to terminal device 102 or clients installed on terminal device 102. A database can be set up on server 104 or independently of server 104 to provide data storage services for server 104.

[0021] The aforementioned network may include, but is not limited to, at least one of the following: wired network and wireless network. The aforementioned wired network may include, but is not limited to, at least one of the following: wide area network (WAN), metropolitan area network (MAN), and local area network (LAN). The aforementioned wireless network may include, but is not limited to, at least one of the following: Wi-Fi (Wireless Fidelity) and Bluetooth. Terminal device 102 may be, but is not limited to, PC (Personal Computer), mobile phone, tablet computer, etc. Server 104 may be, but is not limited to, a cloud server, server cluster, or other server types.

[0022] The query report determination method of this application embodiment can be executed by server 104, terminal device 102, or jointly by server 104 and terminal device 102. Alternatively, the query report determination method of this application embodiment can be executed by a client installed on terminal device 102.

[0023] Taking the method for determining the query report in this embodiment as an example, which is executed by terminal device 102, here, terminal device 102 can be a physical host. The method for determining the query report in this embodiment is applied to the physical host. The memory that the physical host can call is divided into multiple memory levels. One of the multiple memory levels contains at least one type of memory. The multiple memory levels include the first memory level corresponding to the physical memory of the physical host. Here, physical hosts can be enterprise-level servers, cluster servers, office computers, embedded devices, or other physical devices that serve as underlying hardware support in a virtualization environment. Physical memory, on the other hand, is a physical memory module directly connected to the host hardware. It is the core and foundation of the memory architecture. Physical memory is usually composed of Dynamic Random Access Memory (DRAM), which has extremely fast read and write speeds and can respond to the processor's memory access requests with nanosecond-level response times. This makes physical memory suitable for carrying the core code of the virtual machine operating system, frequently called system function libraries, and critical process data that are running at high speeds. For example, at the beginning of virtual machine startup, the operating system kernel needs to quickly load and initialize various hardware drivers and establish a basic system operating environment. At this time, physical memory can complete data read and write operations with extremely high efficiency, ensuring that the virtual machine can start quickly and stably. During the operation of the virtual machine, application parts that have extremely demanding requirements for memory read and write performance, such as the transaction processing module of the database management system and the real-time rendering engine, also rely on physical memory to ensure their efficient operation, thereby maintaining the smoothness and responsiveness of the entire virtual machine system.

[0024] Figure 2 This is a flowchart illustrating an optional method for determining a query report according to an embodiment of this application, as shown below. Figure 2 As shown, the process of this method may include the following steps:

[0025] Step S202: Receive query requests from the target object through multiple input methods, and collect the target object's current query records. The multiple input methods include: voice input, document input, and image input.

[0026] Optionally, in step S202 above, for example, the retrieval enhancement generation system provides an input entry point to receive diverse inputs from users, including but not limited to text, voice, user-uploaded documents (such as PDF, Word, Markdown files), images, screenshots, and other modal information.

[0027] Optionally, in step S202 above, the collected query records include, but are not limited to, the content of the page currently viewed by the user, the content of the page opened in the browser, and the content of the clipboard.

[0028] Step S204: Determine the query task corresponding to the target object based on multiple query requests and the current query record;

[0029] Optionally, in step S202 above, the complex reasoning capabilities of a large language model are mainly utilized to perform in-depth analysis of the user's core intent based on the query request and query records, thereby determining the user's query task. This is because determining the query task solely based on the user's text or voice input may result in insufficient information or ambiguity. By combining multiple pieces of information and the user's query records, the user's query intent can be accurately determined.

[0030] Step S206: Decompose the query task into multiple logical subtasks and assign the multiple logical subtasks to the corresponding query agents respectively.

[0031] Step S208: Determine the query report corresponding to the query task based on the query results of multiple query agents.

[0032] Through the above steps, intent analysis is performed on the input voice, documents, images, and currently viewed content of the target object to determine the query task. Then, based on the implementation logic of the query task, it is decomposed into multiple logical subtasks, which are then assigned to corresponding query agents for processing. Finally, a query report corresponding to the query task is obtained based on the query results of each query agent. This solves the technical problem of inaccurate content generation in existing search enhancement applications, achieving the technical effect of improving the accuracy of generated query results.

[0033] In an exemplary embodiment, before assigning multiple logical subtasks to their respective query agents, the method further includes: obtaining a pre-built agent registry and the capabilities required to execute the multiple logical subtasks, wherein the agent registry includes: multiple query agents, a capability description of each query agent, an idle state of each query agent, and remaining resources of each query agent; determining preliminary query agents corresponding to the multiple logical subtasks from the agent registry based on the capabilities required by the multiple logical subtasks and the capability descriptions of each query agent; and, if the idle states of the multiple preliminary query agents are all idle and the remaining resources of the multiple preliminary query agents allow for the execution of the corresponding logical subtasks, determining the determined multiple preliminary query agents as the query agents corresponding to the multiple logical subtasks.

[0034] Optionally, in the above embodiments, the agent registry contains a capability description, current status (busy or idle), resource consumption, and historical task success rate for each agent. After generating multiple logical subtasks, the system will intelligently schedule different subtasks (such as data query, knowledge retrieval, and code generation) to the corresponding query agents based on the best match between task requirements and agent capabilities (e.g., by calculating the vector similarity between capability descriptions and task descriptions) and the agent's current load.

[0035] Through the task decomposition capabilities and multi-agent collaboration mechanism described in the above embodiments, complex multi-step, cross-domain tasks can be understood and executed. The macro-level user intent is transformed into a series of logically rigorous sub-tasks executed by different expert agents, simulating the collaborative work mode of a human expert team. This upgrades the RGA system from a passive knowledge retrieval tool to a proactive problem-solving platform.

[0036] In an optional embodiment, determining the preliminary query agents corresponding to the multiple logical subtasks from the agent registry based on the capabilities required by the multiple logical subtasks and the capability description of each query agent includes: performing semantic matching between the task requirements of the subtasks and the capability description of each query agent, and determining the query agent with the highest semantic similarity as the execution agent of the logical subtask.

[0037] In an exemplary embodiment, decomposing a query task into multiple logical subtasks includes: determining an implementation logic chain for the query task if it is determined that the query task is not an atomic task, wherein an atomic task represents a task whose objective can be obtained by executing a single instruction; decomposing the query task based on the implementation logic chain to obtain child node tasks; continuing to decompose the child node tasks if it is determined that the child node tasks are not atomic tasks, until all child node tasks are decomposed into atomic tasks; and outputting multiple atomic tasks according to the logical dependencies between the multiple atomic tasks to obtain multiple logical subtasks.

[0038] Optionally, in the above embodiments, complex tasks are mainly decomposed into a series of logical subtasks through the Chain of Thought (CoT). The principle is to recursively decompose macro-tasks into indivisible atomic tasks until each subtask meets the following conditions: single responsibility, solving only one independent problem; executable, able to be solved by directly calling tools, algorithms or knowledge; and stateless, with the output depending only on the current input.

[0039] The logical dependencies between the aforementioned atomic tasks include sequential dependencies (e.g., task A depends on the output of task B) and conditional dependencies (e.g., task B is triggered only when the output of task A meets the condition). In terms of implementation, a directed acyclic graph can be used to model the task topology to determine the task dependencies.

[0040] In an exemplary embodiment, determining the query report corresponding to the query request based on the query results of multiple query proxies includes: obtaining the query results of multiple query proxies and the template parameter requirements of the template corresponding to the query report; processing the multiple query results according to the template parameter requirements to obtain the template parameters corresponding to each of the multiple query results; and filling the template parameters corresponding to each of the multiple query results into the template to obtain the query report.

[0041] Optionally, in the above embodiments, the query report is generated by a preset structured template. Different report templates can be selected according to different query tasks, and then the query report can be obtained by filling the template according to the query results of the query agent.

[0042] In an exemplary embodiment, after determining the query report corresponding to the query request based on the query results of multiple query proxies, the method further includes: when receiving a query request sent by another target object, matching the similarity between the query request sent by the target object and the query request sent by other objects; if the similarity is higher than a preset threshold, directly obtaining multiple logical subtasks and assigning the multiple logical subtasks to their respective query proxies; and determining the query report corresponding to the query request sent by other target objects based on the query results of the multiple query proxies.

[0043] Optionally, in the above embodiments, when another user initiates a similar query request, the CBR (Case-Based Reasoning) engine can match previous successful cases. After fine-tuning the case information, the decomposed tasks can be directly reused, thereby greatly improving the query response speed and the reliability of the results.

[0044] Through the above embodiments, successful task solutions can be stored as case studies for reuse when encountering similar problems in the future. This learning-from-experience mechanism enables the RAG system to become more efficient and reliable over time, significantly reducing the computational overhead and planning time for repetitive tasks, and realizing the intelligent evolution of the RAG system.

[0045] In an exemplary embodiment, determining the query task corresponding to the target object based on multiple query requests and the current query record includes: determining the behavioral profile of the target object based on multiple query requests and the current query record; performing semantic parsing on the content input by the target object to obtain the semantic parsing result; determining the intent of the target object based on the behavioral profile and the semantic parsing result, and generating the query task corresponding to the target object based on the intent.

[0046] Optionally, in the above embodiments, for example, a user uploads a PDF document of a targeted drug clinical trial, and then inputs a core request via microphone: "Based on this document, and by retrieving the latest clinical trial data and authoritative guidelines, comprehensively evaluate the efficacy and risks of this targeted drug for patients, and compare it with standard first-line treatment regimens." Simultaneously, the user is viewing the official website of a cancer study through a browser. After information fusion and processing, it can be determined that the user is a medical researcher studying the effect of a targeted drug on cancer. The query task is to evaluate the efficacy and risks of this targeted drug for patients, conduct a comparative analysis with first-line treatment regimens, and generate a drug evaluation report.

[0047] In an exemplary embodiment, after receiving a query request input by a target object through multiple input methods and collecting the target object's current query records, the method further includes: filtering the current query records according to the query request to obtain filtered query records; assigning different weights to multiple records in the filtered query records according to the query request to obtain weighted query records; and updating the content of the current query records to the weighted query records.

[0048] Optionally, in the above embodiments, the context information from various sources is filtered to remove noise information that is clearly irrelevant to the user's query intent, and then different weights are assigned to the context information from different sources. For example, when performing a query about drug interactions for a specific patient, the current medication list information captured from the patient's electronic medical record page will have the highest weight, while the weight from news websites in browser tabs will be lower.

[0049] In an exemplary embodiment, before determining the query task corresponding to the target object based on multiple query requests and the current query record, the method further includes: performing semantic defect analysis on the multiple query requests and the current query record to obtain semantic defect analysis results, wherein the semantic defect analysis includes ambiguity analysis and information missing analysis; generating an information confirmation list based on the semantic analysis results and sending it to the target object; and obtaining supplementary information of the target object based on the information confirmation list.

[0050] Optionally, in the above embodiments, when the information provided by the user is incomplete or unclear, a series of clarifying questions can be generated to proactively guide the user, gradually narrowing the scope of the questions and clarifying the task objectives.

[0051] In an exemplary embodiment, before assigning multiple logical subtasks to their respective query agents, the method further includes: obtaining a tool list, wherein the tool list includes multiple tools, each tool corresponding to an executable operation unit encapsulated based on a preset protocol; classifying the multiple tools in the tool list based on their functions to obtain multiple tool sets; and generating different query agents and corresponding query capabilities based on the multiple tool sets, wherein each query agent corresponds to an invokable tool set.

[0052] Optionally, in the above embodiments, each query agent is an independent cognitive entity with specific skills and toolsets. The tools in the toolset are obtained by standardizing and encapsulating all the capabilities (application programming interfaces, system instructions, knowledge bases, databases, etc.) available to the agent through MCP (Model Context Protocol).

[0053] The above embodiments solve the problem of the need for extensive hard-coding work when adding new data sources or tools in existing technologies. Through the Model Context Protocol (MCP) and its accompanying dynamic capability discovery and registration center, all capabilities can be abstracted into standardized tools. Any new capability, as long as it is encapsulated and registered according to the MCP specification, can be autonomously discovered and invoked by the agent without modifying upper-layer logic or restarting the system. This greatly reduces the complexity and cost of system integration and maintenance, achieving true hot-swappable capabilities and high scalability.

[0054] In one exemplary embodiment, after obtaining the tool list, the method further includes: obtaining the call request interface of an external application; encapsulating the call request interface into a tool based on a preset protocol; and adding the tool to the tool list.

[0055] Optionally, in the above embodiments, enterprises typically have multiple systems. For example, a hospital may have an electronic medical record system, a medical image archiving and communication system, and a laboratory information management system. If external systems are integrated into the search enhancement generation system, a lot of adaptation work is required. Therefore, the APIs (Application Programming Interfaces) of other external systems can be encapsulated into tools that conform to the MCP specification in the search enhancement generation system, so that the query agent can interact with these heterogeneous systems in a unified way, which greatly improves the integration breadth of the search enhancement generation system.

[0056] In an exemplary embodiment, after assigning multiple logical subtasks to their respective query agents, the method further includes: if it is determined that the query agent initiates a tool call request, determining whether the tool call request requires approval according to a preset approval strategy; if it is determined that approval is required, pushing an approval request window to the target object; after receiving an approval approval instruction from the approval request window, obtaining the target object's identity credentials; and initiating a tool call request using the identity credentials.

[0057] Optionally, in the above embodiments, upon receiving a tool call request, the risk of executing the request is first assessed based on a preset approval policy. If it is a high-risk operation, an approval window will pop up, and execution will only proceed after user approval. Before execution, the user's identity credentials initiating the call, combined with RBAC (Role-Based Access Control) policies, will be used to determine whether the call is permitted. This risk assessment and approval process for tool call requests can also be applied to a single logical subtask.

[0058] The above embodiments provide pre-emptive checks for dangerous operations, prevent abuse of permissions, and meet the urgent security and compliance needs of enterprise applications.

[0059] Through the above embodiments, a multi-agent collaboration mechanism is introduced to effectively decompose, plan, and execute complex cognitive tasks. By standardizing and encapsulating the underlying capabilities and tools through the model context protocol, the retrieval enhancement generation system achieves high flexibility, scalability, and stability, thereby improving the accuracy of retrieval results.

[0060] The following describes an optional method for determining a query report according to an embodiment of this application, with reference to optional embodiments. In one optional embodiment, such as... Figure 3 As shown, the method for determining the query report can be implemented using the following search enhancement generation system. In one optional embodiment, such as... Figure 3 As shown, the above-mentioned retrieval enhancement generation system includes four levels:

[0061] Level 1: Intelligent Interaction and Context Awareness Layer. This layer is the direct interaction interface between the system and the user. Its core objective is to go beyond simple command reception and achieve a deep understanding of the user's intent and a comprehensive awareness of the environmental context, providing the richest and most accurate input information for downstream cognitive planning.

[0062] Level Two: Cognitive Scheduling and Planning Layer. This layer is the core cognitive hub of the entire intelligent system, responsible for transforming the clarified and enriched user intentions transmitted from the upper layers into a specific and executable action plan. It drives the intelligent operation of the entire system by simulating the thinking patterns of human experts and employing a series of advanced cognitive activities such as task decomposition, tool selection, and step arrangement.

[0063] Layer 3: The MCP-driven unified capability and tool layer serves as a crucial bridge connecting cognitive planning with the physical world (various types of data and services). It introduces the Model Context Protocol as a core standard, standardizing and encapsulating all available capabilities (APIs, knowledge bases, databases, etc.) into a service-oriented framework, building a unified and governed capability marketplace.

[0064] Level Four: Persistent Memory and Evolutionary Knowledge Layer. This layer provides the foundation for data persistence, knowledge accumulation, and learning evolution for the entire system. It not only stores static information but also records and utilizes dynamic interaction processes and experiences, enabling the system to become increasingly intelligent over time.

[0065] Optional, such as Figure 3 As shown, the intelligent interaction and context awareness layer includes the following modules:

[0066] 1. Multimodal Unified Interaction Interface: This module provides a unified entry point for receiving diverse user input. It supports not only traditional natural language query text input but also voice, user-uploaded documents (such as PDF, Word, and Markdown files), images, and even screenshots. Internally, this module integrates corresponding parsing and recognition engines. For example, a speech-to-text engine processes audio input, an optical character recognition engine extracts text information from images and screenshots, and a document parsing engine extracts text, tables, image descriptions, and metadata from structured and unstructured documents.

[0067] The key to this module lies in its multimodal information fusion capability. Upon receiving various types of information, it doesn't simply list them, but performs semantic alignment and fusion. For example, in a medical question-and-answer scenario, when a doctor uploads a pathology report image containing tumor markers and asks via voice, "Based on this report and comparing it with the latest NCCN guidelines in the knowledge base, what is the recommended next treatment plan for this patient?", the module will associate the transcribed text with key indicators such as "carcinoembryonic antigen (CEA): 5.2 ng / mL" identified from the image OCR, thus accurately understanding the user's intended meaning. All inputs, after processing, are transformed into a unified, semantically rich internal data structure and passed to downstream modules, achieving seamless support for complex, multi-source inputs.

[0068] 2. Dynamic Context Capture and Construction Module: This module actively or passively captures information about the user's current working environment through browser plugins or deep integration with web applications. For example, when a doctor is accessing an electronic medical record system through a browser, this module can obtain precise information such as the currently viewed patient ID, page link, selected text on the page (such as diagnosis name, drug name, or a description of a condition), and the values ​​of form fields being filled out. It can also capture clipboard content history, allowing users to quickly reference information copied from other places.

[0069] These real-time captured contextual information undergo a context-weighted and filtering mechanism. The system assigns different weights to contextual information from different sources based on task type and historical experience. For example, when performing a query about drug interactions for a specific patient, the current medication list captured from that patient's electronic medical record page will have the highest weight, while page links from other browser tabs (such as news websites) will have a lower weight. The filtering mechanism removes noise information that is clearly irrelevant to the current medical query intent. Ultimately, this processed contextual information is combined with the user's direct input to construct a dynamic, context-rich dialogue scenario, greatly improving the system's accuracy in judging the user's true intent and avoiding the need for users to provide tedious background information descriptions.

[0070] 3. Proactive Clarification and Exploratory Dialogue Engine: When the user's intent transmitted from upstream is ambiguous or lacks sufficient information, this module will initiate a proactive dialogue strategy. Based on the existing context, it will reason and generate a series of clarifying questions or options to ask the user, ensuring that the task has a clear objective before planning begins. For example, in a complex clinical decision support scenario, a user might make a vague request, such as "Please help me analyze the effect of a new drug on lung cancer." This request contains several ambiguities or missing information, such as: Which specific "new drug" is being referred to? Is "lung cancer" small cell or non-small cell lung cancer? Should the focus be on a specific gene mutation? Is the analysis focused on efficacy, risk, or cost? Should specific data sources be limited (such as internal databases or publicly available literature)? At this point, the module will proactively infer based on existing contextual information. For example, if it recognizes that the user has recently mentioned "XZ-853" and "KRAS G12C" mutations multiple times, the system will automatically generate a series of clarifying questions, such as "Is the new drug you mentioned XZ-853?", "Are you focusing on non-small cell lung cancer patients carrying the KRAS G12C mutation?", "Do you want to focus on analyzing efficacy, risks, or drug interactions?", "Do you need to restrict data sources to public channels such as ClinicalTrials.gov (a public database of medical clinical research) or PubMed (a biomedical literature search engine)?" Through this kind of exploratory dialogue, the system can proactively guide clarification before the user has provided complete information and gradually narrow down the scope of questions. Once the user confirms that the analysis objective is "to evaluate the efficacy and risk of the novel targeted drug XZ-853 in patients with KRAS G12C-mutant non-small cell lung cancer, referring to clinical trial data and the latest research literature," the master agent can construct a task thought chain accordingly. This chain might include: "First, retrieving relevant trial data from ClinicalTrials.gov and internal databases; second, using drug interaction analysis tools to assess potential conflicts between XZ-853 and the patient's current medications; third, searching PubMed and BioRxiv (a biomedical article publishing platform) for recent research findings on the drug; and finally, integrating information based on the assessment template and generating a structured report." This task objective identification and decomposition process, starting from a vague intent and driven by clarifying questions, is a key foundation for supporting high-quality system planning and execution.

[0071] 4. Task Impact Assessment and High-Risk Operation Approval Module: Upon receiving a clear task intent, especially when the task may involve modifying system status, deleting data, or accessing critical resources, this module will first conduct a preliminary risk assessment. It will predict the potential impact and risks based on the nature of the task. For operations deemed high-risk (e.g., when a knowledge base administrator intends to perform a high-risk operation such as "batch deletion of all clinical trial data related to 'xx drug' before 2022 from the knowledge base"), the system will automatically generate a structured approval card (i.e., the approval window mentioned above). The lifecycle management of this approval card is as follows:

[0072] Generation and Population: The card clearly lists the operation details, risk level (e.g., high, medium, low), scope of impact (e.g., specific data table, entire service), requester, and request time. The system will also attempt to automatically generate a summary of the "rollback plan".

[0073] Submission notification: Submit to one or more designated approvers (users or administrator groups) through a preset approval workflow, and send notifications via email, instant messaging, or other means.

[0074] Approval interaction: Approver can "approve" or "reject" on the card and add comments.

[0075] Results Feedback: Approval results are provided to the system and users in real time. Only after explicit authorization is obtained will the task be allowed to proceed to the next planning and execution phase, providing a solid guarantee for the safe and stable operation of the system. If approval is rejected, the task process will terminate, and the reason for rejection will be communicated to the user.

[0076] Optional, such as Figure 3 As shown, the cognitive scheduling and planning layer includes the following modules:

[0077] 1. Master Agent and Task Decomposer: As the entry point and overall commander of the cognitive scheduling and planning layer, the master agent receives the complete "dialogue scenario" from the interaction layer. Through the complex reasoning capabilities of a large language model, it performs in-depth analysis and decomposition of the user's core intent. To ensure the quality and logic of the decomposition, this module incorporates several advanced prompt engineering strategies, such as "Chain-of-Thought (CoT)" and "Tree-of-Thought (ToT)".

[0078] For example, when using the CoT strategy, the master agent is guided to think step by step, outputting the logical process of its task decomposition, rather than just the final result. For instance, in a complex clinical decision support scenario, for a macro-level goal such as "evaluating the potential efficacy and risks of a novel targeted drug (XZ-853) in patients with advanced non-small cell lung cancer carrying the KRASG12C mutation, and generating a preliminary assessment report by integrating existing clinical trial data, drug interaction databases, and the latest research literature," the thought process would be as follows: "First, I need to retrieve all information about XZ-853 and KRASG12C from the internal clinical trial database and the external ClinicalTrials.gov." The G12C study... Then, I need to use a drug interaction query tool to check for potential risks between XZ-853 and the patient's current medication list... Next, I need to search for the latest studies on PubMed and BioRxiv, looking for any newly published data on the drug's efficacy or safety... Finally, I need to integrate all the retrieved information and present it in a structured format based on a pre-defined assessment report template. Based on this thought process, the master agent breaks it down into a series of smaller, more specific sub-tasks, such as: Task 1: Search internal and external clinical trial databases; Task 2: Query drug interactions; Task 3: Search the latest medical literature; Task 4: Integrate information and generate an assessment report. This task decomposition capability is the foundation for all subsequent planning and execution.

[0079] 2. Hybrid Planning Engine: Combining autonomous planning and workflow planning modes to meet the needs of different types of RAG tasks.

[0080] Autonomous Planning Mode: For highly exploratory, open-ended questions without a fixed process (such as in a medical research RAG system where a user asks, "Is there a potential link between target X and disease Y, and find relevant evidence?"), the engine will authorize an agent to think autonomously. Based on its built-in knowledge and understanding of available tools, the agent dynamically determines its next action, forming an "Observe-Think-Act" loop. At the core of this loop is a confidence assessment mechanism. For each planned action, the agent assesses the confidence level of its ability to successfully solve the problem. If the confidence level is high, it executes; if the confidence level is low, the agent may choose to call other tools for supplementary information or request a decision from the user, thus avoiding blind trial and error.

[0081] Workflow-driven mode: For standardized tasks with fixed processes and high repetition (e.g., generating standardized monthly follow-up reports for newly enrolled clinical trial patients (ID: P0721), the engine loads a predefined workflow. This workflow precisely defines each step of the task in the form of a directed acyclic graph (e.g., executed sequentially: retrieving the patient's latest laboratory test results from the electronic medical record system, obtaining the latest subjective feelings questionnaire from the patient report results system, checking for new records in the adverse drug event database, and finally generating a report based on the standard follow-up template), dependencies, and execution order. Workflow nodes can be not only atomic tool calls, but also other sub-workflows, or even "exploration nodes" that require autonomous planning, thus achieving a balance between macro-level process determinism and micro-level step flexibility. The query agent acts as a strict executor, ensuring the accuracy and stability of the task flow.

[0082] The aforementioned hybrid planning engine can intelligently select the most suitable planning mode based on the task's metadata (or determined by the master agent), or switch between different stages of the same task, thus balancing flexibility and reliability.

[0083] 3. Multi-Agent Collaboration and Dynamic Scheduling Hub: After tasks are decomposed and initially planned, this module is responsible for efficiently allocating subtasks to the most suitable expert agents (i.e., the query agents mentioned above) and coordinating their collaboration. This module maintains a dynamic registry of all available expert agents, containing each agent's capability description, current status (busy / idle), resource consumption, and historical task success rate. When the master agent generates a task plan, the scheduling hub, like a project manager, intelligently schedules different subtasks (such as data query, knowledge retrieval, and code generation) based on the best match between task requirements and agent capabilities (calculated through vector similarity between capability description and task description) and the agent's current load, distributing them to the corresponding expert agents.

[0084] This module also manages the communication mechanism between agents, which supports multiple communication modes, including:

[0085] Direct messaging: One agent can send messages directly to another designated agent.

[0086] Shared blackboard: All agents can write information to a shared data space, from which other agents can read. This is suitable for scenarios where multiple agents need to share and iterate on the same data.

[0087] Publish-subscribe pattern: One agent can publish events on a specific topic, and other agents that have subscribed to that topic will be notified. This is suitable for loosely coupled event-driven collaboration.

[0088] This collaborative model based on expert agents greatly improves the system's efficiency in handling concurrent and complex tasks.

[0089] 4. Scalable Expert Agent Pool: This module is a pluggable pool of expert agents, each agent being an independent cognitive entity with specific skills and toolsets. For example, the expert agent pool includes:

[0090] Knowledge Retrieval and Enhancement Agent: This agent inherits and enhances the capabilities of traditional RAG. It is proficient in using the knowledge base tools provided at the lower level, capable of performing vector retrieval, full-text search, or hybrid search. Furthermore, based on contextual understanding, it can autonomously decide whether to query a single knowledge base or multiple knowledge bases in parallel. After obtaining initial search results, it invokes an independent re-ranking model to perform a secondary ranking of the results, improving the ranking of the most relevant documents. Finally, it summarizes the ranked information, extracts key entities, and tags information sources, providing other agents with high-quality, traceable knowledge reserves.

[0091] Data Analysis and Code Execution Agent: This agent incorporates a secure sandbox environment (code interpreter) capable of writing and executing scripting languages ​​such as Python. Its execution process is strictly restricted by security policies, such as prohibiting network access, limiting file system read / write permissions, and setting code execution timeouts, ensuring that dynamically generated code does not harm the host system. When tasks require data calculations, chart creation, or invoking complex logic unsuitable for API encapsulation, this agent can dynamically generate code to complete the task, significantly expanding the system's capabilities.

[0092] Medical Evidence Reasoning and Causal Analysis Agent: This agent focuses on constructing complex evidence chains and making causal inferences in clinical research and scientific research tasks. It is capable of processing structured and unstructured evidence from multiple sources (such as PubMed, ClinicalTrials.gov, and guideline documents) and has a built-in language model-driven mechanism for identifying medical causal relationships. When tasks involve causal inference requests such as "Does a targeted drug have a clear therapeutic effect in a specific mutation context?" or "Could the adverse reactions exhibited by this patient be caused by a specific drug?", the agent first retrieves and extracts candidate evidence fragments (including RCTs, meta-analyses, guideline recommendation levels, etc.). Then, combining causal language patterns and Bayesian heuristics, it models and evaluates the supporting relationships between various pieces of evidence, ultimately forming a structured "evidence support matrix" or "causal path diagram" for the controlling agent to integrate subsequent tasks and generate reports. This agent significantly enhances the system's intelligence in complex clinical reasoning, efficacy causal attribution, and evidence-based report writing, and is particularly suitable for scenarios such as medical research support, auxiliary diagnosis and treatment suggestion generation, and advanced scientific research Q&A.

[0093] Other custom agents: This system framework allows developers to flexibly create and register new expert agents based on specific medical business needs, enabling continuous expansion of system capabilities. For example, a "clinical pathway analysis agent" can be created to compare deviations between actual treatment processes and standard clinical pathways; a "guideline consistency verification agent" can be created to verify whether treatment recommendations comply with the latest medical guidelines; a "drug adverse reaction monitoring agent" can be created to analyze the correlation between symptoms reported by patients after medication and previous drug safety data; or a "medical ethics review assistance agent" can be created to assess whether research or treatment plans may involve ethical risks. Through the combination of these agents, a multi-dimensional and professional intelligent collaborative support system for healthcare can be achieved.

[0094] Optional, such as Figure 3 As shown, the unified capabilities and tools layer of the MCP driver includes the following modules:

[0095] 1. Model Context Protocol (MCP) Service Gateway: All requests to underlying capabilities must pass through this gateway. The gateway is responsible for parsing MCP-formatted call requests from upper-layer proxies. This request is typically a structured data (such as JSON) containing "tool_name" (tool name) and "arguments" (input parameters). The gateway queries its internal routing table based on the "tool_name" to find the corresponding backend service, and then replaces the "arguments" with the target service's request format. Upon receiving the response from the backend service, the gateway converts it from a specific format (such as JSON response or protobuf message) back to the MCP standard result format and returns it to the proxies. The MCP service gateway ensures standard communication between the cognitive layer and the capability layer, achieving loose coupling between them. Furthermore, the MCP service gateway also handles basic governance functions such as request authentication, rate limiting, and logging.

[0096] 2. Dynamic Capability Discovery and Registry Center: This module provides a tool list containing all available tools. Any new capability (such as a new API or a newly integrated knowledge base) needs to be registered in this registry center after being encapsulated as an MCP tool. Registration information follows the MCP specification, detailing the tool's name, function (described in natural language for LLM understanding), input parameters (name, JSON structure definition, whether required, description), and output format (JSON structure definition). Upper-layer agents (especially the master agent) can dynamically discover which tools are currently available in the system by calling the "list_tools()" interface provided by this center. During the planning phase, agents semantically match their task requirements with the tool's functional description, enabling autonomous tool selection without manual hard-coding. This achieves "plug-and-play" capability extension without requiring a system restart or redeployment.

[0097] 3. Standardized Knowledge Base Toolset: This module encapsulates operations on various knowledge bases into a series of standardized MCP tools. Examples of some of these tools are provided below:

[0098] The storeKnowledge tool and storeFAQ tool are tools for storing text blocks or question-and-answer pairs into a specified knowledge base.

[0099] The searchKnowledge and searchFAQ tools are core search tools that accept natural language queries. They implement complex search logic, such as hybrid search, multi-path recall, and fusion ranking.

[0100] The `knowledgeBaseSelector` tool is an advanced routing tool that, when a system connects to multiple knowledge bases, intelligently recommends one or more of the most relevant knowledge bases based on the semantics of the query, for further use by the `storeKnowledge` tool. This achieves automatic knowledge base selection, shielding the upper-layer proxy from the complexity of the underlying knowledge bases.

[0101] 4. External System Connectors and Adapters: This module is responsible for encapsulating the APIs of existing, non-MCP-native systems within the enterprise (such as electronic medical record systems, medical image archiving and communication systems, and laboratory information management systems) into tools compliant with MCP specifications using the adapter pattern. Each connector is responsible for handling authentication, API calls, and data format conversion for a specific system, enabling the agent to interact with these heterogeneous systems in a unified manner, greatly improving the breadth of system integration.

[0102] 5. Unified Access Control and Security Governance Module: After receiving a tool call request, the MCP gateway first forwards the request to this module for access control verification. This module determines whether the call is permitted based on the identity of the initiating agent (or the user it represents) and the enterprise's unified RBAC (Role-Based Access Control) policy. For example, in the RAG system of a large healthcare group, a user with the role of "Cardiology Intern" will have their agent restricted to searching only the "Cardiology" and "Public Medical Literature" knowledge bases when calling the searchKnowledge tool, and will not be able to access confidential case data from other departments such as "Oncology". This unified access control, implemented at the capability layer and transparent to agents, ensures that all agent behavior is within a secure and controllable range, preventing access abuse and potential data leakage risks.

[0103] Optional, such as Figure 3 As shown, the persistent memory and evolutionary knowledge layer includes the following modules:

[0104] 1. Unified Knowledge Base: This is the core storage for the system's static knowledge. Behind it is a complete data injection and synchronization pipeline. The pipeline is automatically triggered when a new document is uploaded. Its process includes:

[0105] Document parsing and segmentation: Intelligently extract text based on document type (PDF, MD, etc.) and use semantic segmentation algorithms (such as by chapter or using a sliding window) to divide it into appropriately sized text blocks.

[0106] Metadata extraction: Extract metadata such as title, author, and creation date from the document and associate it with text blocks.

[0107] Vectorization and Indexing: The specified Embedding model is called to convert text blocks into vectors, and the text, metadata, and vectors are stored in the full-text search engine and the vector database, respectively.

[0108] This data injection and synchronization pipeline supports incremental updates, ensuring the timeliness of knowledge base content. The upper-layer knowledge base toolset abstracts this layer, allowing the agent to be unaware of the underlying implementation details.

[0109] 2. Hierarchical Dialogue Memory Module: To achieve truly coherent multi-turn dialogue, this module employs a hierarchical memory mechanism. Specifically, it includes:

[0110] Short-term memory (STM): Stores contextual information of the current conversation at the session level, including the complete message history, intermediate variables, and currently active clarification questions. It is cached to ensure fast access.

[0111] Long-term Memory: After a conversation ends, the system initiates a background task for memory summarization and extraction. This task uses an LLM (Long-Term Memory) to read the complete short-term memory and extract key information points (such as facts confirmed by the user), the user's specific preferences (e.g., in a clinical decision support RAG system, recording whether a physician "pays more attention to NCCN guidelines than ESMO guidelines" or "prefers to prioritize displaying warning boxes over general side effects when viewing drug information"), and the task's final conclusion. The resulting summary is then stored in the user's long-term memory archive. When the user initiates a new conversation, the system can load this archive to provide a more personalized service.

[0112] 3. Experience Accumulation and Case Reasoning Engine: This is the key to the system's learning and evolution. Whenever a complex task is successfully solved, this module will structure and store its complete execution chain—"from the initial user intent, to the task decomposition of the master agent, to the tool call sequence of each expert agent, and the final result"—as a successful case.

[0113] The case representation uses a standardized format, including a vectorized representation of the problem description, a directed acyclic graph structure for task planning, and fields such as tool call logs (success / failure, user satisfaction ratings). When encountering similar tasks in the future, the engine first vectorizes the description of the new problem and then searches the case library (e.g., using the k-nearest neighbor algorithm) to find the most similar historical cases. If a highly similar case is matched, the system can directly reuse or fine-tune its successful task plan, instead of starting from scratch with costly planning each time. This learning-from-experience mechanism significantly improves the system's response speed and problem-solving stability. For example, the system successfully handled a complex request to "query and summarize all Phase I and Phase II clinical trial results of drug XX for a specific gene mutation." When another researcher requests to "find the clinical effects of drug XX on another similar gene mutation," the engine matches the previous successful case and reuses its planning process of "first querying the clinical trial database, then filtering the trial phases, and finally summarizing the results," only replacing the keyword "gene mutation," thereby greatly improving response efficiency and planning reliability.

[0114] 4. End-to-End Behavior Tracking and Observability System: This module is responsible for recording all critical behaviors during system operation, forming a tracking log that can be audited and analyzed. It asynchronously collects and persistently stores the following information:

[0115] The interaction layer receives each raw request and the context it builds.

[0116] Every task breakdown and planning decision made by the cognitive layer, including the underlying thought chain text.

[0117] Each tool call initiated by each agent includes the tool name, input parameters, output results, execution time, token consumption, and whether it was successful.

[0118] Every data read / write operation in the persistence layer.

[0119] This structured tracking data is sent to an observability backend, which not only forms the basis for troubleshooting and performance optimization, but can also be used to generate system behavior analysis reports, such as the most frequently used tools, the most time-consuming task types, and the success rate of agent planning, providing data-driven insights for continuous system iteration and optimization, thereby ensuring system interpretability and compliance.

[0120] Through the above four-layer progressive search enhancement generation system architecture, it not only inherits and surpasses the capabilities of traditional search enhancement generation systems, but also builds a new generation of enterprise-level intelligent system that can understand complex intentions, autonomously plan and execute, efficiently utilize tools, and continuously learn and evolve by introducing advanced agent concepts and MCP standardized protocols.

[0121] In an optional embodiment, the method for determining the query report of this application is described using the search enhancement generation system described in the above embodiments, combined with a specific medical research application scenario. The scenario is set as follows: Dr. Li, an oncologist, is researching a new targeted drug, "XZ-853," and she hopes that the search enhancement generation system can help her comprehensively evaluate the efficacy and safety of this drug in patients with non-small cell lung cancer (NSCLC) carrying the "KRAS G12C" mutation. Specifically, the following steps are included:

[0122] Step 1: Intelligent interaction and context awareness layer performs intent capture and context awareness.

[0123] 1. Multimodal Input: Dr. Li opened the interactive interface of the search enhancement generation system in her browser on her workstation. She uploaded a PDF document of the latest preclinical research on "XZ-853" that she had just downloaded, and then entered her core request via microphone: "Combining this document with the latest clinical trial data and authoritative guidelines, comprehensively evaluate the efficacy and risks of 'XZ-853' in patients with 'KRAS G12C' mutant NSCLC, and compare it with standard first-line treatment regimens."

[0124] 2. Context Capture: At the same time, the plugin deployed on Dr.Li's browser (equivalent to dynamic context capture and context building module) detected that another browser tab she was currently viewing was the official website of a certain National Cancer Network (NCCN), and captured the website link "https:www.***.org" as background information.

[0125] 3. Information Fusion and Processing: The system's backend "Multimodal Unified Interaction Interface" receives the above information. The automatic speech recognition engine converts the speech into text. The document parsing engine extracts key summaries and data from the PDF. The system merges the text request, PDF content, and captured NCCN URL to construct an initial "dialogue scenario" rich in context.

[0126] 4. Proactive Clarification: The proactive clarification and exploratory dialogue engine analyzed the request and found that the phrase "standard first-line treatment regimen" was not clear enough. The system then clarifies by asking Dr. Li: "Do you mean 'standard first-line treatment regimen' specifically refers to the Pembrolizumab combined with chemotherapy regimen? This is the mainstream regimen recommended by the current NCCN guidelines." Dr. Li clicks "Yes" to confirm. At this point, a clear and unambiguous task objective is established and passed on to the next level.

[0127] Step 2: The cognitive scheduling and planning layer performs task planning and proxy scheduling.

[0128] 1. Task Decomposition: After receiving the complete task objective, the master agent uses its built-in thought chain capability to decompose the complex task into a series of logical sub-tasks, generating the following planned task:

[0129] T1: Retrieved and summarized key data from all clinical trials of “XZ-853” for the treatment of “KRAS G12C”-mutant NSCLC in ClinicalTrials.gov and the internal trial database.

[0130] T2: Search PubMed and BioRxiv for the latest research papers or conference abstracts on “XZ-853”, focusing on efficacy and adverse event data.

[0131] T3: Search NCCN guidelines and internal drug knowledge base to obtain efficacy and safety data for Pembrolizumab in combination with chemotherapy as a standard therapy.

[0132] T4: Use the "Drug Interaction" analysis tool to examine the potential drug interaction risks of "XZ-853" based on a sample patient medication list.

[0133] T5: Integrates all information from T1, T2, T3, and T4, performs comparative analysis, and generates a structured report according to the preset "New Drug Evaluation Report Template".

[0134] 2. Planning Mode Selection: The "Hybrid Planning Engine" recognizes this as a task combining exploration and standardization. T1, T2, T3, and T4 rely on tool calls, while T5 is a fixed report generation process. The engine decides to use an autonomous planning-driven agent to execute T1-T4, and then trigger a workflow to execute T5 upon completion.

[0135] 3. Agent Scheduling: The multi-agent collaboration and dynamic scheduling hub receives task plans, queries the agent registry, and performs optimal allocation. T1, T2, and T3 are assigned to the "Knowledge Retrieval and Enhancement Agent," which is proficient in querying various documents and knowledge databases. T4 is assigned to the "Data Analysis and Code Execution Agent" (or a dedicated drug API call agent). The final integration task of T5 is completed by the master agent.

[0136] Step 3: The unified capabilities and tools layer driven by MCP standardize capability calls. The expert agents assigned to tasks begin their work, and all actions of the expert agents are carried out through the "MCP Service Gateway" to call standardized tools.

[0137] 1. The "Knowledge Retrieval and Enhancement Agent" begins execution T1. The knowledgeBaseSelector tool is invoked, and the query "XZ-853 Clinical Trials" is entered. The tool returns the most relevant knowledge base IDs: "kb-clinical-trials-gov" and "kb-internal-trials".

[0138] 2. The "Knowledge Retrieval and Enhancement Agent" initiates two parallel calls to the searchKnowledge tool to retrieve the two knowledge bases mentioned above.

[0139] 3. Before invoking the tool, the "Unified Permission Verification and Security Governance Module" intercepts the request and verifies whether Dr. Li's role (oncologist) has permission to access the internal database "kb-internal-trials". Once the verification is successful, the "MCP Service Gateway" routes the request to the corresponding backend search engine.

[0140] 4. After the retrieved information is optimized by the agent's internal "reordering model", key data is extracted, source links are attached, and the information is stored in the collaboration blackboard.

[0141] 5. Similarly, the “Data Analysis Agent” calls an MCP tool called “checkDrugInteractions”, which is an API of a commercial drug database encapsulated by the “External System Connector”.

[0142] Step 4: The persistent memory and evolutionary knowledge layer synthesize the results and accumulate knowledge.

[0143] Once all subtasks are completed, the master agent begins the final integration process.

[0144] 1. After all subtasks are completed, the master agent begins the final integration work, reading the results submitted by all expert agents from the collaboration blackboard. These results are already structured and traceable.

[0145] 2. The lead agent fills in the information from the above submission results according to the requirements of the "New Drug Evaluation Report Template" to generate a complete report including efficacy comparison, safety analysis, potential risks and references, and presents it to Dr. Li.

[0146] 3. Dialogue Memory: After the dialogue ends, the "Hierarchical Dialogue Memory Module" summarizes the key points of this interaction ("Dr. Li pays attention to XZ-853", "Standard treatment is confirmed as Pembrolizumab regimen") and stores them in Dr. Li's "Long-term Memory Archive".

[0147] 4. Experience Accumulation: Since Dr. Li gave the report a "satisfactory" rating, the "Experience Accumulation and Case Reasoning Engine" stored the entire successful task execution chain, "from the clarified problem to the five-step planning of the master agent, and then to the specific tool call sequence of each agent," as a complete "success case" in the case library.

[0148] 5. Behavior Tracking: Every step in this process, from Dr. Li's initial click to each MCP tool call and its time consumption and token consumption, has been recorded by the "End-to-End Behavior Tracking and Observability System" and sent to the dashboard for administrators to monitor performance and audit behavior.

[0149] In the future, when another doctor makes a request similar to "evaluating the efficacy of the new drug Y against KRAS G12C mutations," the CBR engine will be able to match previous successful cases and directly reuse its mature five-step planning process, thereby greatly improving response speed and the reliability of results.

[0150] The above embodiments demonstrate how a complex cognitive task can be completed efficiently, reliably, and securely through hierarchical collaboration, standardized tools, and continuous learning mechanisms.

[0151] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (e.g., read-only memory (ROM) / random access memory (RAM), magnetic disk, optical disk), and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods of the various embodiments of this application.

[0152] According to another aspect of the embodiments of this application, a query report determining apparatus is also provided. This query report determining apparatus can be used to implement the query report determining method provided in the above embodiments, and will not be repeated hereafter. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0153] Figure 4This is a structural block diagram of an optional query report determining device according to an embodiment of this application, such as... Figure 4 As shown, the device for determining the query report includes:

[0154] The information receiving module 42 is used to receive query requests input by the target object through multiple input methods, and to collect the current query records of the target object. The multiple input methods include: voice input, document input, and image input.

[0155] The task determination module 44 is used to determine the query task corresponding to the target object based on multiple query requests and the current query record.

[0156] The task decomposition module 46 is used to decompose the query task into multiple logical subtasks and assign the multiple logical subtasks to the corresponding query agents.

[0157] The report determination module 48 is used to determine the query report corresponding to the query task based on the query results of multiple query agents.

[0158] The query report determination device provided in this application analyzes the intent of the target object's input (voice, document, image, and currently browsed content) to determine the target object's query task. Then, based on the query task's implementation logic, the query task is decomposed into multiple logical sub-tasks, which are then assigned to corresponding query agents for processing. Finally, a query report corresponding to the query task is obtained based on the query results from each query agent. This solves the technical problem of inaccurate content generation in existing search enhancement applications, achieving the technical effect of improving the accuracy of generated query results.

[0159] In an exemplary embodiment, the task decomposition module 46 is configured to obtain a pre-built proxy registry and the capabilities required to execute multiple logical subtasks. The proxy registry includes: multiple query proxies, a capability description of each query proxies, an idle state of each query proxies, and remaining resources of each query proxies. Based on the capabilities required by the multiple logical subtasks and the capability descriptions of each query proxies, the module determines preliminary query proxies corresponding to the multiple logical subtasks from the proxy registry. If the idle states of the multiple preliminary query proxies are all idle and the remaining resources of the multiple preliminary query proxies allow for the execution of the corresponding logical subtasks, the determined multiple preliminary query proxies are designated as the query proxies corresponding to the multiple logical subtasks.

[0160] In an exemplary embodiment, the task determination module 44 is configured to determine the implementation logic chain of the query task when it is determined that the query task is not an atomic task, wherein an atomic task represents a task whose objective can be obtained by executing a single instruction; decompose the query task based on the implementation logic chain to obtain sub-node tasks; continue to decompose the sub-node tasks when it is determined that the sub-node tasks are not atomic tasks, until multiple sub-node tasks are decomposed into atomic tasks; and output multiple atomic tasks according to the logical dependencies between multiple atomic tasks to obtain multiple logical sub-tasks.

[0161] In an exemplary embodiment, the report determination module 48 is used to obtain the query results of multiple query agents and the template parameter requirements of the template corresponding to the query report; process the multiple query results according to the template parameter requirements to obtain the template parameters corresponding to the multiple query results respectively; and fill the template parameters corresponding to the multiple query results into the template to obtain the query report.

[0162] In an exemplary embodiment, the report determination module 48 is configured to, upon receiving a query request sent by another target object, match the similarity between the query request sent by the target object and the query request sent by other objects; if the similarity is higher than a preset threshold, directly obtain multiple logical subtasks and assign the multiple logical subtasks to the corresponding query agents respectively; and determine the query report corresponding to the query request sent by the other target object based on the query results of the multiple query agents.

[0163] In an exemplary embodiment, the task determination module 44 is used to determine the behavioral profile of the target object based on multiple query requests and the current query record; perform semantic parsing on the content input by the target object to obtain the semantic parsing result; determine the intent of the target object based on the behavioral profile and the semantic parsing result, and generate the query task corresponding to the target object based on the intent.

[0164] In an exemplary embodiment, the information receiving module 42 is configured to filter the content of the current query record according to the query request to obtain the filtered query record; assign different weights to multiple records in the filtered query record according to the query request to obtain the weighted query record; and update the content of the current query record to the weighted query record.

[0165] In an exemplary embodiment, the task determination module 44 is used to perform semantic defect analysis on multiple query requests and the current query record to obtain semantic defect analysis results, wherein the semantic defect analysis includes ambiguity analysis and information missing analysis; generate an information confirmation list based on the semantic analysis results and send it to the target object; and obtain supplementary information of the target object based on the information confirmation list.

[0166] In an exemplary embodiment, the task decomposition module 46 is used to obtain a tool list, wherein the tool list includes multiple tools, each tool corresponding to an executable operation unit encapsulated based on a preset protocol; classify the multiple tools in the tool list based on their functions to obtain multiple toolsets; and generate different query agents and corresponding query capabilities based on the multiple toolsets, wherein each query agent corresponds to a callable toolset.

[0167] In one exemplary embodiment, the task decomposition module 46 is used to obtain the call request interface of an external application; encapsulate the call request interface into a tool based on a preset protocol; and add the tool to the tool list.

[0168] In an exemplary embodiment, the task decomposition module 46 is configured to, when it is determined that the query agent has initiated a tool call request, determine whether the tool call request requires approval according to a preset approval strategy; if it is determined that approval is required, push an approval request window to the target object; after receiving the approval approval instruction from the approval request window, obtain the identity credentials of the target object; and initiate a tool call request using the identity credentials.

[0169] The description of the features in the embodiment corresponding to the above-mentioned query report determination device can be found in the relevant description of the embodiment corresponding to the query report determination method, and will not be repeated here.

[0170] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above-described embodiments of the query report determination method.

[0171] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described methods for determining query reports when it is run.

[0172] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0173] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described methods for determining query reports.

[0174] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described methods for determining query reports.

[0175] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0176] The foregoing has provided a detailed description of the method, apparatus, storage medium, and electronic device of a distributed storage system provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and its core ideas. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A method for determining a query report, characterized in that, include: The system receives query requests from a target object via multiple input methods, and collects the target object's current query records. The multiple input methods include: voice input, document input, and image input. The query task corresponding to the target object is determined based on the multiple query requests and the current query record; The query task is decomposed into multiple logical subtasks, and the multiple logical subtasks are respectively assigned to the corresponding query agents; The query report corresponding to the query task is determined based on the query results of the multiple query agents; Before assigning the plurality of logical subtasks to their respective query agents, the method further includes: obtaining a pre-built agent registry and the capabilities required to execute the plurality of logical subtasks, wherein the agent registry includes: a plurality of query agents, a capability description of each query agent, an idle state of each query agent, and remaining resources of each query agent; determining preliminary query agents corresponding to the plurality of logical subtasks from the agent registry based on the capabilities required by the plurality of logical subtasks and the capability descriptions of each query agent; and, if the idle states of the plurality of preliminary query agents are all idle and the remaining resources of the plurality of preliminary query agents allow for the execution of the corresponding logical subtasks, determining the determined plurality of preliminary query agents as the query agents corresponding to the plurality of logical subtasks.

2. The method according to claim 1, characterized in that, The query task is decomposed into multiple logical subtasks, including: If it is determined that the query task is not an atomic task, the implementation logic chain of the query task is determined, wherein the atomic task refers to a task whose target can be obtained by executing a single instruction; Based on the aforementioned implementation logic chain, the query task is decomposed to obtain sub-node tasks; If it is determined that the sub-node task is not the atomic task, the sub-node task is decomposed again until all the sub-node tasks are decomposed into the atomic task. Based on the logical dependencies between the multiple atomic tasks, the multiple atomic tasks are output to obtain the multiple logical subtasks.

3. The method according to claim 1, characterized in that, The query report corresponding to the query request is determined based on the query results of multiple query proxies, including: Obtain the query results from the multiple query proxies, as well as the template parameter requirements corresponding to the query report; The multiple query results are processed according to the template parameter requirements to obtain the template parameters corresponding to the multiple query results respectively; The template parameters corresponding to the multiple query results are filled into the template to obtain the query report.

4. The method according to claim 1, characterized in that, After determining the query report corresponding to the query request based on the query results of multiple query proxies, the method further includes: When a query request is received from another target object, the similarity between the query request sent by the target object and the query request sent by the other object is matched. If the similarity is higher than a preset threshold, the multiple logical subtasks are directly obtained and assigned to the corresponding query agents respectively. The query report corresponding to the query request sent by the other target object will be determined based on the query results of the multiple query proxies.

5. The method according to claim 1, characterized in that, Determining the query task corresponding to the target object based on multiple query requests and the current query record includes: Determine the behavioral profile of the target object based on the multiple query requests and the current query record; The semantic parsing of the input content of the target object is performed to obtain the semantic parsing result; The intent of the target object is determined based on the behavioral profile and the semantic parsing results, and a query task corresponding to the target object is generated based on the intent.

6. The method according to claim 1, characterized in that, After receiving query requests from the target object through multiple input methods and collecting the current query records of the target object, the method further includes: Based on the query request, the current query record is filtered to obtain the filtered query record; For multiple records in the filtered query records, different weights are assigned to the multiple records according to the query request to obtain weighted query records; Update the content of the current query record to the weighted query record.

7. The method according to claim 1, characterized in that, Before determining the query task corresponding to the target object based on multiple query requests and the current query record, the method further includes: Semantic defect analysis is performed on the multiple query requests and the current query record to obtain semantic defect analysis results, wherein the semantic defect analysis includes ambiguity analysis and information missing analysis; An information confirmation list is generated based on the semantic analysis results and sent to the target object; Obtain supplementary information for the target object based on the information confirmation list.

8. The method according to claim 1, characterized in that, Before assigning the plurality of logical subtasks to their respective query proxies, the method further includes: Obtain a tool list, wherein the tool list includes multiple tools, and each tool corresponds to an executable operation unit encapsulated based on a preset protocol; The tools in the tool list are categorized based on their functions to obtain multiple tool sets; Different query agents and corresponding query capabilities are generated based on the multiple toolsets, wherein each query agent corresponds to a callable toolset.

9. The method according to claim 8, characterized in that, After obtaining the list of tools, the method further includes: Obtain the API call request interface of external applications; The call request interface is encapsulated into a tool based on the preset protocol; Add the tool to the tool list.

10. The method according to claim 8, characterized in that, After assigning the multiple logical subtasks to their respective query proxies, the method further includes: If it is determined that the query agent initiates a tool call request, it is determined whether the tool call request needs to be approved according to a preset approval strategy; If approval is required, an approval request window is pushed to the target object. After receiving the approval instruction from the approval request window, obtain the identity credentials of the target object; The tool invocation request is initiated using the identity credentials.

11. A task scheduling device, characterized in that, include: The information receiving module is used to receive query requests input by the target object through multiple input methods, and to collect the current query records of the target object. The multiple input methods include: voice input, document input, and image input. The task determination module is used to determine the query task corresponding to the target object based on the multiple query requests and the current query record. The task decomposition module is used to decompose the query task into multiple logical subtasks and assign the multiple logical subtasks to the corresponding query agents respectively. The report determination module is used to determine the query report corresponding to the query task based on the query results of the multiple query agents; The task decomposition module is further configured to obtain a pre-built proxy registry and the capabilities required to execute the plurality of logical subtasks. The proxy registry includes: a plurality of query proxies, a capability description for each query proxies, the idle state of each query proxies, and the remaining resources of each query proxies. Based on the capabilities required by the plurality of logical subtasks and the capability descriptions of each query proxies, preliminary query proxies corresponding to the plurality of logical subtasks are determined from the proxy registry. If the idle states of the plurality of preliminary query proxies are all idle, and the remaining resources of the plurality of preliminary query proxies allow for the execution of the corresponding logical subtasks, the determined plurality of preliminary query proxies are designated as the query proxies corresponding to the plurality of logical subtasks.

12. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the method for determining a query report as described in any one of claims 1 to 10 when executing the computer program.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the method for determining a query report as described in any one of claims 1 to 10.

14. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method for determining a query report as described in any one of claims 1 to 10.

Images