A structured data context isolation addressing and multi-layer cache analysis method and device for large language model agent tool invocation, and electronic equipment

Abstract

Embodiments of the present application provide a structured data context isolation addressing and multi-layer cache analysis method, device and electronic equipment for large language model Agent tool invocation, which relates to the field of artificial intelligence data processing. The method comprises: calling a data acquisition tool to obtain a structured data set of an analysis object and a data set index Key thereof; based on the data set index Key, concurrently starting multiple independent analysis tracks, and after completion of analysis, storing analysis result data to a persistent index layer and an object storage layer, and generating an analysis result identification Key; and based on the analysis result identification Key of each track, the server autonomously reads each dimension analysis result data from the persistent index layer and the object storage layer, and after merging and processing, generates a structured comprehensive analysis report. The technical solution solves problems such as context window pollution, cross-tool data transmission redundancy, lack of efficient cache mechanism for LLM analysis results, and lack of fault tolerance and breakpoint resume capability for analysis pipeline.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence data processing technology, and more specifically, to a structured data context isolation addressing and multi-layer caching analysis method, apparatus and electronic device for large language model Agent tool calls. Background Technology

[0002] With the rapid development of Large Language Model (LLM) technology, AI Agent tool invocation frameworks, represented by Model Context Protocol (MCP), have gradually become the core architecture of intelligent analysis platforms. Under this architecture, LLM Agents encapsulate external capabilities (such as data querying, analysis and calculation, report generation, etc.) into callable tools through a declarative tool registration and invocation mechanism. The LLM Agent autonomously determines the invocation order and parameters during the inference process, forming a multi-tool collaborative analysis pipeline.

[0003] In the existing LLM Agent tool invocation framework, data transfer between tools follows a standard pattern: after a tool completes execution, its return result is injected in full text form into the LLM Agent's ContextWindow. The LLM Agent then performs inference and judgment based on all the information in the context, and then passes the data that needs to be passed to the next tool as parameters. In other words, all intermediate data in the toolchain must be transferred through the LLM context—the output of the upstream tool enters the context, and the LLM extracts information from the context and passes it to the input of the downstream tool.

[0004] This full pass-through model of "tool output → LLM context → downstream tool input" works well in scenarios involving short text and small amounts of data. However, when the analysis task involves large-scale collections of structured documents (such as corporate patent document databases, academic paper collections, financial report collections, legal judgment document collections, etc., where a single analysis object can contain dozens to hundreds of documents, each containing multiple long text fields), this model exposes serious architectural flaws.

[0005] Furthermore, in terms of caching and fault tolerance, existing LLM Agent tool invocation frameworks typically treat tools as stateless function calls, without providing a persistent caching mechanism for tool return results, nor do they provide intermediate state management and breakpoint recovery capabilities for multi-step toolchains. Summary of the Invention

[0006] The embodiments of this application provide a structured data context isolation addressing and multi-layer caching analysis method, apparatus and electronic device for large language model Agent tool calls, in order to solve the technical problems existing in the prior art.

[0007] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part from practice of this application.

[0008] According to a first aspect of the embodiments of this application, a structured data context isolation addressing and multi-layer caching analysis method for large language model Agent tool calls is provided, including: Step S100: Invoke the data acquisition tool to obtain the structured data set of the analysis object and its data set index Key; Step S200: Based on the data set index Key, multiple independent analysis tracks are started concurrently. After the analysis is completed, the analysis result data is stored in the persistent index layer and the object storage layer, and an analysis result identifier Key is generated. In step S300, the server autonomously reads the analysis result data of each dimension from the persistent index layer and object storage layer based on the analysis result identifier Key of each track, and generates a structured comprehensive analysis report after merging and processing.

[0009] In some embodiments of this application, based on the foregoing scheme, the step of invoking the data acquisition tool to obtain the structured data set of the analysis object and its data set index key includes: The document data of the analysis object is obtained and deduplicated to obtain a structured data set. In the structured data set, each document record includes a title, summary, classification code and body text. Write the complete serialized data of the structured data set into the object storage layer according to the storage path organized by the analysis object identifier and analysis mode parameters; The data set index key is constructed based on the analysis object identifier and analysis mode parameters.

[0010] In some embodiments of this application, based on the foregoing scheme, the construction of the data set index Key based on the analysis object identifier and analysis mode parameters includes: After serializing the analysis object identifier and analysis mode parameters, an opaque short string is generated using a deterministic reversible encoding method. This string serves as the unique reference handle for the structured data set and is denoted as the data set index key.

[0011] In some embodiments of this application, based on the foregoing scheme, the concurrent initiation of multiple independent analysis tracks based on the data set index Key includes: Perform a reverse decoding operation on the dataset index key to restore the analysis object identifier and analysis mode parameters, and locate the data path in the object storage; the data returned to the LLM Agent only includes the dataset index key and the statistical summary information of the dataset, and does not include the original document data; The server autonomously reads the complete document data of the analysis object from the object storage layer according to the data path, inputs it into multiple analysis tracks, and performs analysis simultaneously through an asynchronous concurrency mechanism.

[0012] In some embodiments of this application, based on the foregoing scheme, after the analysis is completed, the analysis result data is stored in a persistent index layer and an object storage layer, and an analysis result identifier key is generated, including: Write the complete serialized data of the analysis results to the object storage layer; The index metadata of the analysis results data is written to the persistent index layer. The index metadata includes the following fields: analysis object identifier, analysis type, analysis mode, object storage path, expiration timestamp, and result summary text. The concatenated string of analysis type, analysis object identifier, and analysis mode is used as input. A fixed-length string is calculated using a deterministic hash function and serves as the unique and irreversible identifier of the analysis result, denoted as the analysis result identifier Key.

[0013] In some embodiments of this application, based on the foregoing scheme, the server autonomously reads analysis result data for each dimension from the persistent index layer and the object storage layer based on the analysis result identifier key for each track, including: Based on the analysis result identifier key, the index metadata of the analysis result data is matched from the persistent index layer, while expired data is filtered out based on the expiration timestamp; Once a match is found, the complete serialized data of the analysis results is read from the object storage layer.

[0014] In some embodiments of this application, based on the foregoing scheme, an in-process session cache layer is provided before the persistent index layer; The in-process session cache layer is implemented using an in-process hash table, where the key is a tuple consisting of the analysis object identifier, analysis type, and analysis mode, and the value is the analysis result data with a timestamp. When querying the cache, the query proceeds through the in-process session cache layer, persistent index layer, and object storage layer in that order. If any layer is hit, the result is returned directly.

[0015] In some embodiments of this application, based on the aforementioned scheme, a non-blocking fault-tolerant strategy is adopted for write operations of the persistent index layer and the object storage layer: when a write fails, only log information is recorded, no exception is thrown to the caller, and the normal return of analysis results is not affected; In the persistent index layer, a combined unique key is formed by three fields: analysis object identifier, analysis type, and analysis mode. An idempotent write strategy is adopted during writing, so that repeated write operations for the same analysis task update existing records without generating duplicate records.

[0016] In some embodiments of this application, based on the foregoing scheme, the method further includes a breakpoint resumption mechanism: Each analysis track in step S100 and step S200, as well as step S300, are treated as independent pipeline execution units. After each execution unit is completed, its output index key and complete result data are written to persistent storage through the persistent index layer and object storage layer, and the completion status of the execution unit is recorded. When any execution unit fails, the system returns a partially completed response, which carries a set of result identifiers (Keys) for all completed execution units and the identifier information of the failed execution unit. Based on the response, the caller resumes execution only from the failed execution unit. The results of the completed execution units are directly reused within the cache validity period without recalculation. According to a second aspect of the embodiments of this application, a structured data context isolation addressing and multi-layer caching analysis apparatus for large language model agent tool calls is provided, comprising: The acquisition unit is used to call the data acquisition tool to obtain the structured data set of the analysis object and its data set index key; The generation unit is used to concurrently start multiple independent analysis tracks based on the data set index key, and after the analysis is completed, store the analysis result data to the persistent index layer and the object storage layer, and generate the analysis result identifier key; The analysis unit is used by the server to autonomously read analysis result data from the persistent index layer and object storage layer based on the analysis result identifier key of each track, and generate a structured comprehensive analysis report after merging and processing.

[0017] According to a third aspect of the embodiments of this application, an electronic device is provided, including: a memory and a processor; The memory is used to store computer instructions; The processor is configured to invoke computer instructions stored in the memory, causing the electronic device to execute the method described in the first aspect.

[0018] The technical solution of this application has the following beneficial effects: (1) The LLM context consumption is significantly reduced. Through the data set index key mechanism, regardless of the size of the document set being analyzed (tens to hundreds of documents, each containing thousands of words), the increased context load on the LLM Agent side remains constant with each tool call, consisting only of the index key string and statistical summary, typically not exceeding 200 tokens. This is because the entire original document text is stored in the server-side object storage layer, and the tool's return value does not contain any original text data. This reduces the context token consumption from linearly increasing with document size (the original model) to a fixed constant level, fundamentally eliminating the problem of the LLM context window being occupied by the original document text.

[0019] (2) Efficient reuse of analysis results across tools Through the analysis result identification key mechanism, the output of each analysis tool is transmitted in the toolchain in the form of a fixed-length short string. Downstream tools or report generation tools only need to hold the analysis result identification key to allow the server to independently retrieve the complete analysis results from the storage layer, without needing to transfer large data objects through the LLM context. This mechanism completely eliminates redundant data transmission in the toolchain, reduces network I / O burden, and allows the context resources of the LLM Agent to be concentrated on inference and scheduling.

[0020] (3) The analysis results cache hit rate is high, and the response speed and cost are significantly optimized. The three-layer caching system is differentiated to address the "large volume and high recalculation cost" characteristics of LLM analysis results: The first layer, the in-process cache, eliminates the I / O overhead of repeated requests within the same process, with a hit response time in the millisecond range; the second layer, the relational database index layer, achieves cross-process and cross-session cache reuse through precise SQL queries and expiration time filtering, reducing the hit response time to sub-second to second level; the third layer, the object storage layer, handles large text content without increasing the database burden, with a hit response time in the second range. This three-layer collaboration ensures that, within the cache's validity period, repeated analysis requests for the same analysis object do not trigger any LLM API calls, reducing the response time from minutes to milliseconds to seconds.

[0021] (4) Improved reliability of production lines The breakpoint resume mechanism, combined with a persistent caching system, ensures that if any step in the multi-step analysis pipeline fails, the calculation results of all completed steps are persistently stored. The caller can resume execution from the failed step instead of starting from scratch. This is particularly crucial for large-scale analysis tasks that take several minutes to over ten minutes in total, effectively improving the completion rate and user experience of long-running analysis tasks.

[0022] (5) The architecture has good decoupling and strong scalability. The storage separation design of "index layer stores references, storage layer stores entities," along with the mechanism for the server to independently decode keys and retrieve data, completely decouples the LLM Agent from the underlying storage system. The underlying relational database and object storage services can be independently expanded in capacity or replaced with components (e.g., replacing MySQL with PostgreSQL, or MinIO with AWS S3) without affecting the definition and invocation method of the LLM Agent tool interface.

[0023] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0024] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort. In the drawings: Figure 1 A flowchart illustrating a structured data context isolation addressing and multi-layer caching analysis method for large language model Agent tool calls according to an embodiment of this application is shown. Figure 2 This diagram illustrates the overall architecture of a structured data intelligent analysis system applying the method according to an embodiment of this application; Figure 3 A three-layer cache structure and access flowchart according to an embodiment of this application are shown; Figure 4 A schematic diagram of a resume download process according to an embodiment of this application is shown; Figure 5 A block diagram of a structured data context isolation addressing and multi-layer caching analysis apparatus for large language model Agent tool calls according to an embodiment of this application is shown; Figure 6 A block diagram of an electronic device according to one embodiment of this application is shown; Figure 7 A schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application is shown. Detailed Implementation

[0025] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided to make this application more comprehensive and complete, and to fully convey the concept of the exemplary embodiments to those skilled in the art.

[0026] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.

[0027] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0028] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0029] It should be noted that "multiple" in this article refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0030] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such uses of these terms can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described.

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

[0032] The following detailed description of some embodiments of this application will be provided in conjunction with the accompanying drawings. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0033] Existing technologies have the following significant drawbacks when handling large-scale structured document analysis tasks: (1) Context window pollution problem The number of documents analyzed typically ranges from dozens to hundreds, with each document containing numerous text fields such as title, abstract, classification code, and body text. In the existing tool call framework's full-pass-through mode, the raw document data directly enters the LLM Agent's context window via the tool's return value. A single call can consume tens to hundreds of thousands of tokens, causing the LLM's limited context window to be heavily occupied by the original document text. This severely compresses the Agent's available context space for inference, planning, and result aggregation, and may even lead to call failure due to exceeding the context length limit.

[0034] (2) Redundancy issues in cross-tool data transfer In multi-tool collaborative analysis pipelines (such as calling a data scoring tool first, then a comprehensive evaluation tool, and finally a report generation tool), each tool needs to receive the complete analysis results from the previous step as input. Existing methods rely on LLM contexts for relaying data, resulting in the same large dataset being repeatedly serialized to the context, extracted by the LLM, and then passed downstream at each stage of the toolchain, causing a significant waste of context resources and network bandwidth.

[0035] (3) LLM analysis results lack an efficient caching mechanism LLM-driven analysis tasks (such as comprehensive scoring of document collections and multi-dimensional expert analysis) are computationally very expensive, typically requiring calls to commercial LLM APIs. A single analysis can take several minutes and incur significant API call costs. Because existing frameworks treat tools as stateless calls, repeated analysis requests for the same analysis object trigger a full recalculation each time, and there is a lack of persistent caching mechanisms for LLM analysis results, resulting in a significant waste of time and money.

[0036] (4) Analysis of the lack of fault tolerance and breakpoint resume capability in the pipeline. Comprehensive analysis of large-scale documents typically involves multiple sequential or parallel steps (data acquisition → multi-dimensional scoring → comprehensive analysis → report generation), with a total time consumption that can range from several minutes to over ten minutes. In existing solutions, failure of any intermediate step causes the entire analysis process to stop, and intermediate results of completed steps are lost due to lack of persistence. The caller must then re-execute the entire process from the beginning, severely impacting user experience and system reliability.

[0037] To address the shortcomings of the existing technology, this application provides a structured data context isolation addressing and multi-layer caching analysis method for large language model agent tool calls, which specifically solves the following technical problems: 1. How to pass and reference large-scale structured data sets in the LLM Agent toolchain while avoiding the original document text occupying the LLM context window; 2. How to efficiently identify and reuse intermediate analysis results across tool calls, avoiding redundant transfer of large data objects through LLM contexts; 3. How to establish a persistent, multi-level caching system for high-cost LLM analysis results to achieve fast response when the cache is hit; 4. How to implement fault tolerance and breakpoint resumption in a multi-step analysis pipeline to ensure that the calculation results of completed steps are not lost.

[0038] See Figure 1 The diagram illustrates a flowchart of a structured data context isolation addressing and multi-layer caching analysis method for large language model Agent tool calls according to an embodiment of this application.

[0039] like Figure 1 As shown, a structured data context isolation addressing and multi-layer caching analysis method for large language model Agent tool calls is demonstrated, specifically including steps S100 to S300.

[0040] refer to Figure 1 Step S100: Call the data acquisition tool to obtain the structured data set of the analysis object and its data set index Key.

[0041] In some feasible embodiments, based on the foregoing scheme, the step of invoking the data acquisition tool to obtain the structured data set of the analysis object and its data set index key includes: The document data of the analysis object is obtained and deduplicated to obtain a structured data set. In the structured data set, each document record includes a title, summary, classification code and body text. Write the complete serialized data of the structured data set into the object storage layer according to the storage path organized by the analysis object identifier and analysis mode parameters; The data set index key is constructed based on the analysis object identifier and analysis mode parameters.

[0042] In some feasible embodiments, based on the foregoing scheme, constructing the data set index Key based on the analysis object identifier and analysis mode parameters includes: After serializing the analysis object identifier and analysis mode parameters, an opaque short string is generated using a deterministic reversible encoding method. This string serves as the unique reference handle for the structured data set and is denoted as the data set index key.

[0043] Understandably, in this embodiment, the analysis object identifier and analysis mode parameters are compressed into opaque short strings through reversible encoding, serving as lightweight reference handles for large-scale structured data sets. The server autonomously locates and reads data through reverse decoding, and the LLM Agent context does not carry any original data. The core value of this design lies not in the reference handle itself (the reference / handle pattern is already used in traditional distributed systems), but in the specialized optimization for the unique and scarce resource of the LLM Agent's context window—its design goal is to isolate data entities outside the Agent's context window, reducing the consumption of context tokens from linearly increasing with data size to a fixed constant, thus solving the window pollution problem caused by the full injection of tool return values ​​into the context in existing LLM Agent tool invocation frameworks.

[0044] For example, participate Figure 2 The diagram shows the overall architecture of a structured data intelligent analysis system that applies this method.

[0045] like Figure 2 As shown in this example, the process of generating the dataset index key specifically includes: When the LLM Agent invokes the data acquisition tool to obtain a structured collection of documents for the target analysis object, the server performs the following steps: Step S101: Obtain structured document data of the target analysis object from one or more data sources, and form a structured data set after deduplication and merging. In the structured data set, each document record contains structured fields such as title, summary, category code, and body text.

[0046] Step S102: Write the complete serialized data of the structured data set to the object storage service. The save path is organized according to the analysis object identifier and analysis mode parameters, and the format is {object identifier} / {analysis mode} / data.json.

[0047] Step S103: Construct the data set index Key. After serializing the analysis object identifier and analysis mode parameters, generate an opaque short string using a deterministic reversible encoding method, which serves as the unique reference handle for the structured data set.

[0048] The server can perform reverse decoding on this key to restore the analysis object identifier and analysis mode parameters, thereby locating the data path in the object storage and retrieving the data. In this example, base64url encoding is used.

[0049] The reversible encoding method is not limited to base64url; other encoding or mapping schemes that can achieve bidirectional conversion, such as base62 encoding and UUID mapping tables, can also be used.

[0050] It should be noted that the return value of the data acquisition tool only includes the data set index key and statistical summary information of the data set (such as the total number of documents, the number of contributions from each data source, etc.), and does not include any original document data. Therefore, regardless of the actual number of documents in the document set or the length of each document, the context load received by the LLM Agent remains at a consistently low level.

[0051] Continue to refer to Figure 1 In step S200, based on the data set index Key, multiple independent analysis tracks are started concurrently. After the analysis is completed, the analysis result data is stored in the persistent index layer and the object storage layer, and an analysis result identifier Key is generated.

[0052] In some feasible embodiments, based on the foregoing scheme, the concurrent initiation of multiple independent analysis tracks based on the data set index key includes: Perform a reverse decoding operation on the dataset index key to restore the analysis object identifier and analysis mode parameters, and locate the data path in the object storage; the data returned to the LLM Agent only includes the dataset index key and the statistical summary information of the dataset, and does not include the original document data; The server autonomously reads the complete document data of the analysis object from the object storage layer according to the data path, inputs it into multiple analysis tracks, and performs analysis simultaneously through an asynchronous concurrency mechanism.

[0053] In some feasible embodiments, based on the foregoing scheme, after the analysis is completed, the analysis result data is stored in a persistent index layer and an object storage layer, and an analysis result identifier key is generated, including: Write the complete serialized data of the analysis results to the object storage layer; The index metadata of the analysis results data is written to the persistent index layer. The index metadata includes the following fields: analysis object identifier, analysis type, analysis mode, object storage path, expiration timestamp, and result summary text. The concatenated string of analysis type, analysis object identifier, and analysis mode is used as input. A fixed-length string is calculated using a deterministic hash function and serves as the unique and irreversible identifier of the analysis result, denoted as the analysis result identifier Key.

[0054] Understandably, in this embodiment, a deterministic hash operation is performed on the combination of analysis type, analysis object identifier, and analysis mode to generate a fixed-length, irreversible, unique identifier. The analysis result identifier key is used to share analysis result references across multiple tool call chains, eliminating the problem of redundant transfer of large data objects through LLM contexts in the toolchain. The analysis result identifier key also serves as an idempotent write key in the persistent index table, enabling precise location of cached records and preventing duplicate writes. A different generation strategy (irreversible hashing vs. reversible encoding) is used compared to the data set index key because the complete metadata of the analysis result is independently stored in the index table; the key itself does not need to carry decodable information, only ensuring uniqueness and determinism.

[0055] Understandably, in this embodiment, the multi-dimensional analysis tasks are designed as independent concurrent tracks. Each track is ultimately converged only through the analysis result identifier key, with no direct data coupling between tracks. The report generation tool only receives the set of analysis result identifier keys for each dimension. The server autonomously pulls data from the storage layer for each dimension and merges and processes it, achieving a completely decoupled multi-dimensional analysis concurrency framework. This design allows adding a new analysis dimension to simply add a new concurrent track and the corresponding analysis result identifier key, without affecting existing tracks and report generation logic.

[0056] For example, the process of generating the analysis result identifier key includes: Step S201: Write the complete serialized data of the analysis results to the object storage service, and save it in the path {object identifier} / {analysis type}_{analysis mode}.json.

[0057] Step S202: Write the index metadata of the analysis results into the cache index table of the relational database. The index metadata includes the following fields: analysis object identifier, analysis type, analysis mode, object storage path, expiration timestamp, and result summary text. The result summary text is a concise textual summary of the analysis results, with a length limited to a preset threshold (512 characters in this example), used to provide the LLM Agent with lightweight reference information in the context.

[0058] Step S203: Calculate the analysis result identifier Key. The concatenated string of analysis type, analysis object identifier, and analysis pattern is used as input. A deterministic hash function is used to calculate a fixed-length string, which serves as the unique and irreversible identifier for the analysis result. In this example, the SHA-256 hash algorithm is used, outputting a 64-character hexadecimal string. The hash algorithm is not limited to SHA-256; other cryptographic hash algorithms such as SHA-3, BLAKE2, and BLAKE3, or digest algorithms capable of generating deterministic and unique identifiers, can also be used.

[0059] It should be noted that the return value of the analysis tool only includes the analysis result identifier Key and the result summary text in step S202, and does not include the original analysis result text.

[0060] It's important to note that when the report generation tool is invoked, it receives a set of analysis result identifier keys (corresponding to the results for each analysis dimension). The server then queries the corresponding object storage path from the cache index table based on each key, autonomously reads the analysis results for each dimension, merges and processes them, and generates the final report. During this process, the LLM Agent does not participate in the transfer of any analysis result data.

[0061] In some feasible embodiments, based on the aforementioned scheme, an in-process session cache layer is provided before the persistent index layer; The in-process session cache layer is implemented using an in-process hash table, where the key is a tuple consisting of the analysis object identifier, analysis type, and analysis mode, and the value is the analysis result data with a timestamp. When querying the cache, the query proceeds through the in-process session cache layer, persistent index layer, and object storage layer in that order. If any layer is hit, the result is returned directly.

[0062] In some feasible embodiments, based on the aforementioned scheme, a non-blocking fault tolerance strategy is adopted for write operations of the persistent index layer and object storage layer: when a write fails, only log information is recorded, no exception is thrown to the caller, and the normal return of analysis results is not affected. In the persistent index layer, a combined unique key is formed by three fields: analysis object identifier, analysis type, and analysis mode. An idempotent write strategy is adopted during writing, so that repeated write operations for the same analysis task update existing records without generating duplicate records.

[0063] It should be noted that in this embodiment, a three-layer caching structure is established. When a cache hit occurs, each layer directly returns the cached result. When a cache miss occurs, the query proceeds to the next lower layer until an actual calculation is triggered when a cache miss still occurs. For example, see Figure 3 The diagram illustrates the three-layer cache structure and access flow.

[0064] like Figure 3 As shown: First layer: In-process session cache The in-process session cache is implemented using an in-process hash table. Its data structure is in key-value pair format, where the key is a tuple consisting of the analysis object identifier, analysis type, and analysis mode, and the value is the analysis result data with a timestamp. During reading, the timestamp is checked in real time. If the difference between the current time and the write time exceeds a preset lifespan threshold (10 minutes in this embodiment), it is considered expired and discarded. This cache layer is not persistent, does not share across processes, and is automatically cleared when the process restarts. Its design goal is to provide the fastest access path with zero I / O overhead for short-term repeated requests within the same process.

[0065] Second layer: Persistent index layer The persistent index layer is implemented using a relational database (MySQL in this embodiment) to store the metadata index of the analysis results. The fields in the cached index table include: analysis object identifier, analysis type, analysis mode, object storage path (pointing to the specific storage location in the third layer), expiration timestamp, result summary text, and analysis result identifier key. Among these, the analysis object identifier, analysis type, and analysis mode fields constitute a composite unique key.

[0066] During the query, precise matching is performed based on the analysis object identifier, analysis type, and analysis mode, while filtering out expired timestamps to exclude expired records. Upon a match, the complete analysis results are retrieved from the third layer based on the object's storage path; if the corresponding stored object in the third layer has been deleted or corrupted, it is considered a complete miss and the process is pushed down to the actual calculation, with automatic repair capabilities.

[0067] During writing, an idempotent write strategy is adopted (in this embodiment, the INSERT ... ON DUPLICATE KEYUPDATE statement is used) to ensure that repeated writing to the same analysis task does not generate duplicate records.

[0068] This layer follows the principle of storage separation: it only stores reference paths and lightweight metadata, and does not store the full content of analysis results, in order to keep the database lightweight and performant queries.

[0069] Third layer: Object storage layer The object storage layer is implemented using an S3-compatible object storage service (MinIO in this embodiment), storing the complete serialized content of the analysis results. Storage paths are organized according to the analysis object identifier and analysis type. The default lifespan is 30 days, with logical expiration managed through the expiration timestamp field in the second-level cache index table.

[0070] The second and third layers work together to achieve a storage separation architecture where "the index layer stores references and the storage layer stores entities," preventing the relational database from expanding due to large text storage, while object storage can be independently expanded in capacity.

[0071] Cache write-back mechanism and fault tolerance principle: Once the actual calculation is complete, the system writes the results to both the second layer (index metadata) and the third layer (complete content) simultaneously. For write failures in the cache layer, this invention employs a non-blocking fault-tolerance strategy: when a write to the third layer fails, only a warning log is recorded; when a write to the second layer fails, only an error log is recorded. Neither throws exceptions to the caller, ensuring the main business process returns the analysis results normally. This design ensures that a failure in the cache subsystem will not cause the analysis task itself to fail.

[0072] Understandably, in this embodiment, considering the unique characteristics of LLM analysis results—"large volume, high recalculation cost, and high short-term repetition rate"—a three-layer differentiated cache is designed: First layer: in-process cache (millisecond response, zero I / O) → Second layer: relational database index layer (sub-second / second response, precise SQL matching + TTL filtering, reference-only storage) → Third layer: object storage content layer (second-level response, large text storage). The three layers adopt a separate architecture of "index layer storing references, storage layer storing entities," keeping the relational database lightweight and efficient. A non-blocking fault-tolerant design ensures that a write failure in any cache layer does not affect the main analysis process. This caching system works closely with the dataset index key and the analysis result identifier key—the key mechanism provides the cache layer with precise addressing and indexing, while the cache layer provides efficient data access support for the key mechanism; together, they constitute a complete data management architecture.

[0073] Continue to refer to Figure 1 In step S300, the server autonomously reads the analysis result data of each dimension from the persistent index layer and object storage layer based on the analysis result identifier Key of each track, and generates a structured comprehensive analysis report after merging and processing.

[0074] In some feasible embodiments, based on the aforementioned scheme, the server autonomously reads analysis result data for each dimension from the persistent index layer and the object storage layer based on the analysis result identifier key for each track, including: Based on the analysis result identifier key, the index metadata of the analysis result data is matched from the persistent index layer, while expired data is filtered out based on the expiration timestamp; after a match is found, the complete serialized data of the analysis result data is read from the object storage layer.

[0075] In some feasible embodiments, based on the foregoing scheme, the method further includes a breakpoint resumption mechanism: Each analysis track in step S100 and step S200, as well as step S300, are treated as independent pipeline execution units. After each execution unit is completed, its output index key and complete result data are written to persistent storage through the persistent index layer and object storage layer, and the completion status of the execution unit is recorded. When any execution unit fails, the system returns a partially completed response, which carries a set of result identifiers (Keys) for all completed execution units and the identifier information of the failed execution unit. Based on the response, the caller resumes execution only from the failed execution units. The results of completed execution units are directly reused within the cache's validity period without recalculation. For example, participants... Figure 4 The diagram illustrates the process of resuming interrupted downloads.

[0076] It is understandable that, such as Figure 4 As shown, by tracking step status and persisting intermediate results (each step is written to persistent storage via a three-layer caching system upon completion), breakpoint resumption is achieved when any step fails: the system returns a partial status and all results of completed steps; the caller can resume execution from only the failed steps, and the calculation results of completed steps can be directly reused within the cache's validity period without recalculation. This mechanism relies on the synergy of context isolation addressing and multi-layer caching analysis—it is precisely because the result of each step is uniquely identified by the analysis result identifier key and persisted via a three-layer caching system that breakpoint resumption has a feasible basis.

[0077] Below are some specific implementation examples.

[0078] Implementation Case 1: Analysis of Enterprise Patent Technology Strength (Standard Model) This embodiment uses corporate patent documents as structured document data, and assesses the company's technological strength by analyzing the collection of patents held by the company, illustrating the complete workflow of this invention. Combined with... Figure 2 and Figure 4 Please provide an explanation.

[0079] Implementation environment: The LLM Agent adopts the Claude model, the tool invocation protocol adopts MCP (Model Context Protocol), the server adopts the FastAPI framework, the relational database adopts MySQL, the object storage adopts MinIO, and asynchronous concurrency adopts Python asyncio.

[0080] Step 1 (Data Acquisition, corresponding to Step 1 of the pipeline): The LLM Agent calls the data acquisition tool get_company_patents("Beijing XXX Technology Co., Ltd.", mode="sample"). The server retrieves the company's patent data in parallel from the local patent database and external commercial data sources (such as Tianyancha API). After deduplication and merging, a collection of patent documents is obtained (43 patents in this example, each containing fields such as title, abstract, IPC classification number, claims, and description).

[0081] The server writes the complete JSON of the patent collection to MinIO (path: enterprise-data / beijing-moumou-keji / sample / patents.json) and generates the data collection index key: data_index_key = base64url('["Beijing XXX Technology Co., Ltd.","sample"]')= "WyLljJfkuqzmn5Dmn5Dnp5HmioAiLCJzYW1wbGUiXQ" (Example value) The tool returned the following values: {total_count: 43, local_count: 15, tyc_count: 28, data_index_key: "WyLljJ..."}. The LLM Agent context increased by approximately 150 tokens, with no original patent text.

[0082] Step 2 (Multi-dimensional parallel analysis, corresponding to pipeline Step 2): The agent concurrently calls three analysis tracks using the data_index_key: Track A (serial dependency): First, call score_patents("Beijing XX Technology Co., Ltd.", data_index_key="WyLljJ..."). After the server decodes the Key, it reads the full text of the patent set from MinIO, starts an LLM concurrent thread pool to perform multi-dimensional scoring for each patent (four dimensions: innovativeness, practicability, technical complexity, and protection scope). After completion, the scoring results are written into MinIO and a cache index record is created in MySQL, and result_key_D = SHA-256("score_patents|Beijing XX Technology Co., Ltd.|sample") is generated. Then call analyze_tech(data_index_key, patent_scores_result_key=result_key_D). This tool relies on the measured scoring values of the previous step to perform a comprehensive assessment of technical capabilities, and generates result_key_T after completion. The two steps in Track A must be executed serially, because the technical capability assessment relies on the scoring results of each individual patent.

[0083] Track B (independent concurrency): Call expert_analysis("Beijing XX Technology Co., Ltd.", data_index_key="WyLljJ..."). After the server decodes the Key to obtain the patent set, it simulates multiple experts from different fields to perform independent analysis and evaluation concurrently, and generates result_key_E after completion.

[0084] Track C (independent concurrency): Call web_search_company("Beijing XX Technology Co., Ltd."), search for enterprise technology-related information from public network information sources, perform multi-dimensional information cleaning and organization, and generate result_key_W after completion.

[0085] The three tracks are executed concurrently via asyncio.gather(), and there is no data dependency between the tracks.

[0086] Step 3 (report aggregation generation, corresponding to pipeline Step 3): The Agent aggregates the four analysis result identifier Keys and calls the report generation tool: generate_enterprise_report(company_name="Beijing XX Technology Co., Ltd.",result_keys={"tech_scores": result_key_T,"patent_scores": result_key_D,"expert": result_key_E,"web_search": result_key_W}).

[0087] The server queries the corresponding MinIO path from MySQL for each key, autonomously reads the complete JSON of the analysis results from each dimension, merges them, and generates a structured Markdown-formatted enterprise technical strength analysis report, which includes chapters such as enterprise fundamentals, patent technology scores, comprehensive assessment of technical capabilities, expert opinions, and analysis of publicly available information.

[0088] Throughout the process, only about 500 tokens of key strings and statistical summaries appeared in the LLM Agent context, with no original patent text or analysis results being passed through the context.

[0089] Implementation Case 2: Resuming Data After Pipeline Interruption During the concurrent execution of Step 2 in Case Study 1, if track B (expert_analysis()) fails due to a network timeout, the system behavior is as follows: Tracks A and C were completed successfully, and their respective analysis results have been persisted through a three-layer caching system: the complete JSON of the analysis results was written to MinIO, the index metadata was written to MySQL, and the corresponding result_key_T, result_key_D, and result_key_W have been generated and are available.

[0090] Step 2 returns a response indicating the partial completion status: {"status": "partial","completed_steps": ["patents_fetch", "tech_scores", "patent_scores", "web_search"],"failed_step": "expert_analysis","data": {"tech_scores": { "result_key": result_key_T, "one_liner": "..."},"patent_scores": { "result_key": result_key_D, "one_liner": "..."},"web_search": { "result_key": result_key_W, "one_liner": "..."}} } The caller (or the LLM Agent, after making its own determination) only needs to re-call the `expert_analysis(data_index_key)` tool to complete track B. Since the patent dataset can still be obtained from MinIO via `data_index_key` (no need to re-fetch), this call only performs the expert analysis step.

[0091] After obtaining result_key_E, the Agent possesses all four analysis result identifiers (Keys) and can normally call generate_enterprise_report(result_keys={...}) to generate the final report. The entire recovery process does not require re-executing Step 1 (data acquisition) and the successfully completed tracks A and C in Step 2, significantly shortening the compensation execution time.

[0092] The following describes an apparatus embodiment of this application, which can be used to execute a structured data context isolation addressing and multi-layer caching analysis method for large language model Agent tool calls as described in the above embodiments of this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the method described in the above embodiments of this application.

[0093] Reference Figure 5 As shown, a structured data context isolation addressing and multi-layer caching analysis apparatus 500 for large language model Agent tool calls, according to an embodiment of this application, includes: The acquisition unit 501 is used to call the data acquisition tool to obtain the structured data set of the analysis object and its data set index key; The generation unit 502 is used to concurrently start multiple independent analysis tracks based on the data set index key, and after the analysis is completed, store the analysis result data to the persistent index layer and the object storage layer, and generate the analysis result identifier key; Analysis unit 503 is used by the server to autonomously read the analysis result data of each dimension from the persistent index layer and object storage layer based on the analysis result identifier key of each track, and generate a structured comprehensive analysis report after merging and processing.

[0094] like Figure 6 As shown, this application embodiment also provides an electronic device 600, including a memory 610, a processor 620, and a computer program 611 stored in the memory 610 and executable on the processor. When the processor 620 executes the computer program 611, it implements the steps of the above-mentioned structured data context isolation addressing and multi-level caching analysis method for calling large language model Agent tools.

[0095] Since the electronic device described in this embodiment is the device used to implement the structured data context isolation addressing and multi-layer cache analysis device for calling large language model Agent tools in this application embodiment, those skilled in the art can understand the specific implementation method and various variations of the electronic device in this embodiment based on the method described in this application embodiment. Therefore, how the electronic device implements the method in this application embodiment will not be described in detail here. Any device used by those skilled in the art to implement the method in this application embodiment is within the scope of protection of this application.

[0096] In practice, when the computer program 611 is executed by the processor, it can implement any of the embodiments corresponding to the first aspect.

[0097] Figure 7 A schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application is shown.

[0098] It should be noted that, Figure 7 The computer system 700 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0099] like Figure 7 As shown, the computer system 700 includes a Central Processing Unit (CPU) 701, which can perform various appropriate actions and processes based on programs stored in Read-Only Memory (ROM) 702 or programs loaded from storage portion 708 into Random Access Memory (RAM) 703, such as performing the methods described in the above embodiments. The RAM 703 also stores various programs and data required for system operation. The CPU 701, ROM 702, and RAM 703 are interconnected via a bus 704. An Input / Output (I / O) interface 705 is also connected to the bus 704.

[0100] The following components are connected to I / O interface 705: an input section 706 including a keyboard, mouse, etc.; an output section 707 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 708 including a hard disk, etc.; and a communication section 709 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 709 performs communication processing via a network such as the Internet. A drive 710 is also connected to I / O interface 705 as needed. A removable medium 711, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on drive 710 as needed so that computer programs read from it can be installed into storage section 708 as needed.

[0101] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 709, and / or installed from removable medium 711. When the computer program is executed by central processing unit (CPU) 701, it performs various functions defined in the system of this application.

[0102] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium, a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such transmitted data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0103] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. Each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0104] The units described in the embodiments of this application can be implemented in software or hardware, and the described units can also be located in a processor. The names of these units do not necessarily limit the specific unit itself.

[0105] In another aspect, this application also provides a computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the structured data context isolation addressing and multi-level caching analysis method for large language model agent tool calls described in the above embodiments.

[0106] In another aspect, this application also provides a computer-readable medium, which may be included in the electronic device described in the above embodiments; or it may exist independently and not assembled into the electronic device. The computer-readable medium carries one or more programs, which, when executed by the electronic device, cause the electronic device to implement the structured data context isolation addressing and multi-layer caching analysis method for large language model Agent tool calls described in the above embodiments.

[0107] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to the embodiments of this application, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0108] Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, touch terminal, or network device, etc.) to execute the methods according to the embodiments of this application.

[0109] Other embodiments of this application will readily conceive of by those skilled in the art upon consideration of the specification and practice of the embodiments disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. It should be understood that this application is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A structured data context isolation addressing and multi-layer caching analysis method for large language model agent tool calls, characterized in that, include: Step S100: Invoke the data acquisition tool to obtain the structured data set of the analysis object and its data set index Key; Step S200: Based on the data set index Key, multiple independent analysis tracks are started concurrently. After the analysis is completed, the analysis result data is stored in the persistent index layer and the object storage layer, and an analysis result identifier Key is generated. In step S300, the server autonomously reads the analysis result data of each dimension from the persistent index layer and the object storage layer based on the analysis result identifier Key of each track, and generates a structured comprehensive analysis report after merging and processing. The method of concurrently launching multiple independent analysis tracks based on the data set index key includes: Perform a reverse decoding operation on the dataset index key to restore the analysis object identifier and analysis mode parameters, and locate the data path in the object storage; the data returned to the LLM Agent only includes the dataset index key and the statistical summary information of the dataset, and does not include the original document data; The server autonomously reads the complete document data of the analysis object from the object storage layer according to the data path, inputs it into multiple analysis tracks, and performs analysis simultaneously through an asynchronous concurrency mechanism; After the analysis is completed, the analysis results are stored in the persistent index layer and the object storage layer, and an analysis result identifier key is generated, including: Write the complete serialized data of the analysis results to the object storage layer; The index metadata of the analysis results data is written to the persistent index layer. The index metadata includes the following fields: analysis object identifier, analysis type, analysis mode, object storage path, expiration timestamp, and result summary text. The concatenated string of analysis type, analysis object identifier, and analysis mode is used as input. A fixed-length string is calculated using a deterministic hash function and serves as the unique and irreversible identifier of the analysis result, denoted as the analysis result identifier Key.

2. The method according to claim 1, characterized in that, The process of calling the data acquisition tool to obtain the structured data set of the analysis object and its data set index key includes: The structured data and document data of the analysis object are obtained and deduplicated to obtain a structured data set. In the structured data set, each document record includes a title, summary, classification code and body text. Write the complete serialized data of the structured data set into the object storage layer according to the storage path organized by the analysis object identifier and analysis mode parameters; Construct a data set index Key based on the analysis object identifier and analysis mode parameters; The construction of the data set index Key based on the analysis object identifier and analysis mode parameters includes: After serializing the analysis object identifier and analysis mode parameters, an opaque short string is generated using a deterministic reversible encoding method. This string serves as the unique reference handle for the structured data set and is denoted as the data set index key.

3. The method according to claim 1, characterized in that, The server autonomously reads analysis result data from the persistent index layer and object storage layer based on the analysis result identifier key for each track, including: Based on the analysis result identifier key, the index metadata of the analysis result data is matched from the persistent index layer, while expired data is filtered out based on the expiration timestamp; Once a match is found, the complete serialized data of the analysis results is read from the object storage layer.

4. The method according to claim 1 or 3, characterized in that, An in-process session cache layer is provided before the persistent index layer; The in-process session cache layer is implemented using an in-process hash table. The key is a tuple consisting of the analysis object identifier, analysis type, and analysis mode, and the value is the analysis result data with a timestamp. The timestamp is checked in real time during reading. If the difference between the current time and the write time exceeds the preset survival time threshold, it is considered expired and the cache entry is discarded. When querying the cache, the query proceeds through the in-process session cache layer, persistent index layer, and object storage layer in that order. If any layer is hit, the result is returned directly.

5. The method according to claim 1, characterized in that, For write operations in the persistent index layer and object storage layer, a non-blocking fault tolerance strategy is adopted: when a write fails, only log information is recorded, no exception is thrown to the caller, and the normal return of analysis results is not affected. In the persistent index layer, a combined unique key is formed by three fields: analysis object identifier, analysis type, and analysis mode. An idempotent write strategy is adopted during writing, so that repeated write operations for the same analysis task update existing records without generating duplicate records.

6. The method according to claim 1, characterized in that, The method also includes a breakpoint resume mechanism: Each analysis track in step S100 and step S200, as well as step S300, are treated as independent pipeline execution units. After each execution unit is completed, its output index key and complete result data are written to persistent storage through the persistent index layer and object storage layer, and the completion status of the execution unit is recorded. When any execution unit fails, the system returns a partially completed response, which carries a set of result identifiers (Keys) for all completed execution units and the identifier information for the failed execution unit. Based on the response, the caller resumes execution only from the failed execution unit. The results of the completed execution units are directly reused within the cache validity period without recalculation.

7. A structured data context isolation addressing and multi-layer caching analysis device for large language model agent tool calls, applied to the method as described in any one of claims 1-6, characterized in that, include: The acquisition unit is used to call the data acquisition tool to obtain the structured data set of the analysis object and its data set index key; The generation unit is used to concurrently start multiple independent analysis tracks based on the data set index key, and after the analysis is completed, store the analysis result data to the persistent index layer and the object storage layer, and generate the analysis result identifier key; The analysis unit is used by the server to autonomously read analysis result data from the persistent index layer and object storage layer based on the analysis result identifier key of each track, and generate a structured comprehensive analysis report after merging and processing.

8. An electronic device, characterized in that, include: Memory and processor; The memory is used to store computer instructions; The processor is configured to invoke computer instructions stored in the memory, causing the electronic device to perform the method as described in any one of claims 1-6.

Images