Service platform based on multi-modal automatic configuration and application method thereof

Abstract

The invention relates to the technical field of computers, in particular to a service platform based on multi-modal automatic configuration and an application method thereof, according to the service platform and the application method, a service configuration cache acceleration unit is deployed, and a service registry, a behavior predictor, a popularity monitoring agent, a cache controller and depth perception combined dependence are combined; and dynamically planning cache allocation and loading in combination with multi-modal user behavior prediction and component popularity. The service platform based on multi-modal automatic configuration and the application method thereof solve or at least relieve the problems of incomplete loading and response delay caused by the fact that an existing system does not fully consider complex dependence among components in service configuration, improve service starting reliability and efficiency, optimize cache utilization, and improve service starting efficiency. And the robustness and the intelligent level of the system are enhanced.

Description

Technical Field

[0001] This invention belongs to the field of computer technology, and in particular relates to a service platform based on multimodal automated configuration and its application method. Background Technology

[0002] Against the backdrop of deepening global economic integration and accelerated digital transformation, the demand for intelligent service platforms in areas such as cross-border trade and customs supervision has exploded. These platforms, by integrating diverse business functions and automated processing capabilities, aim to significantly improve the efficiency, transparency, and compliance of trade processes. Especially when dealing with massive amounts of import and export data, complex trade rules, and volatile market dynamics, a highly intelligent service platform that can respond quickly, be flexibly configured, and is highly strategic is of irreplaceable strategic significance for reducing operating costs, optimizing resource allocation, and enhancing international competitiveness. Therefore, technological innovation in this field has consistently revolved around how to build a more efficient, reliable, and adaptable service system.

[0003] To address the aforementioned challenges, the industry has developed and deployed a series of import and export trade management systems in the existing technology. For example, Chinese Patent Publication No. CN118071526B discloses an import and export trade management system that achieves service configuration based on user needs through the collaborative work of the system end, user end, transportation service end, dispatch service end, and client end, and incorporates multiple process modules. The system also specifically mentions a financial module, deeply managing costs, revenues, and accounts receivable, helping to solve problems such as unclear order finances and reconciliation, greatly improving the clarity and accuracy of reconciliation. The emergence of some technical solutions implicitly addresses the pain points of information asymmetry and chaotic financial management in traditional trade, promoting the standardization and transparency of business processes. However, when supporting modular service configuration, existing systems often fail to consider the complex cohesion relationships between service components in their underlying data caching and resource loading mechanisms. That is, users can be provided with different business combination modules for on-demand configuration, but these modules are usually not independent atomic entities, but rather service combinations formed by connecting smaller, interconnected service components (such as specific UI components, logic units, business rules, shared resource libraries, etc.). Therefore, when a system attempts to load or start a service combination, the caching mechanism often tends to handle each service component individually, or perform predictive loading based solely on popularity and frequency rules. Thus, even if a main service combination is cached in the system, if its dependent sub-services or shared resources are not marked as "hotspots" and therefore not in the cache, the service combination may still fail to start successfully. Alternatively, after loading, it may require time to retrieve source data and complete dependencies. From the user's perspective, this manifests as UI lag, service delays, or even failure to start. In short, even if the main service component is cached, if its dependent sub-services or shared resources are not, the service combination cannot start, or after starting, it may experience loading delays due to missing data and dependencies.

[0004] For high-concurrency, low-latency business scenarios in cross-border transaction systems, such as cross-border trade and customs supervision, there are numerous user behaviors and dynamic configuration requirements, posing significant performance challenges. Currently, the complexity of service component dependency structures, when not adequately addressed, leads to two outcomes: incomplete cache loading and wasted cache resources. For example, if the system preloads numerous independent components that do not form a complete and usable service combination, it results in incomplete cache usage. Alternatively, if the system fails to predict and preload all dependencies of a complete service combination, under high concurrency, numerous concurrent requests will encounter missing dependencies and attempt to load the same missing component. This not only increases the load on the backend storage system but also causes cache thrashing, where the cache frequently loads evicted data, reducing the effective hit rate and impacting the overall stability and reliability of the system. Furthermore, for newly launched functional modules or low-frequency service components that are only occasionally triggered in specific scenarios but are crucial, the current cache, lacking in-depth review and protection of their "criticality," is prone to being evicted first. When these components are needed, they have to be loaded from scratch, which not only increases latency but also significantly reduces the system's robustness and the reliability of service startup. Furthermore, the existing platform's shortcomings in multimodal recognition and automated configuration support further limit its potential to provide truly intelligent services in complex and dynamic scenarios, making it unable to perform proactive and intelligent service configuration prediction and caching optimization based on multi-dimensional information such as user behavior and role context. Summary of the Invention

[0005] The purpose of this invention is to overcome the shortcomings of the prior art, solve or at least alleviate the problems of incomplete service loading, response delay, and inefficient use of cache resources caused by the failure of the underlying data caching and resource loading mechanism of the existing system to fully consider the complex internal dependencies between service components when processing service composition. The invention provides a service platform based on multimodal automated configuration and its application method.

[0006] To achieve the above objectives, the present invention provides the following technical solution: a service platform based on multimodal automated configuration, comprising: The service configuration cache acceleration unit is configured on the server motherboard expansion interface and includes non-volatile memory and a programmable controller. The non-volatile memory is divided into multiple main cache slots, and each main cache slot can be further divided into multiple sub-cache slots for storing independent service components and their dependent resources in the storage service portfolio. The service registry is used to store metadata and internal dependency graphs of registered service combinations. A behavior predictor is used to combine user roles and action sequences to output a list of candidate service combinations; A popularity monitoring agent is used to query the multi-dimensional popularity of service combinations and their components under the current user role. The cache controller receives the dependency graph, multidimensional popularity, and prediction confidence, and dynamically plans the cache loading strategy based on the dependency structure.

[0007] To further realize the present invention, the following technical solutions may be preferred: Preferably, the service configuration cache acceleration unit is connected to the main processor via a dedicated high-speed interface; the non-volatile memory adopts high read / write speed non-volatile memory technology; the programmable controller is a hybrid architecture of application-specific integrated circuit and field-programmable gate array, and the integrated register array is used to store dependency graph, hot data and cache mapping; the main cache slot and sub-cache slot support dynamic allocation, and the programmable controller supports direct memory access to achieve low-latency loading.

[0008] Preferably, the service registry stores service composition metadata including unique identifiers, version information, a list of service components, and key dependency flags; the dependency graph adopts a directed acyclic graph structure, where nodes represent service components or shared resources, and edges represent calls or data dependencies; the service registry provides the dependency graph to the behavior predictor and cache controller through a standard interface, and actively pushes changes when services are updated.

[0009] Preferably, the behavior predictor employs a sequence prediction model, with inputs including user roles, historical operation sequences, and system status, and outputs a list of candidate service combinations and prediction confidence; the model is incrementally trained based on user behavior logs.

[0010] Preferably, the heat monitoring agent calculates a multi-dimensional heat score for the "user role-service composition-component" triple based on service call logs, taking into account call frequency and time decay; the heat score is periodically written to the register of the cache acceleration unit; if the heat of the core component is lower than the threshold, an early warning is sent to the cache controller.

[0011] An application method for a service platform based on multimodal automated configuration, applicable to the aforementioned service platform, includes: S1: Deploy the cache acceleration unit and inject dependency metadata, including dividing the main cache slot and sub-cache slot, parsing the service composition dependency graph, building a multi-dimensional heat profile and writing it to the controller; S2: Dependency-aware prediction is triggered when the user configures the system, including outputting candidate combinations from the behavior predictor, parsing their dependency structure, verifying the completeness of the prediction path, querying multidimensional popularity, and starting dependency-aware scheduling. S3: Perform dependency-driven cache loading, including evaluating loading integrity requirements, checking component cache status, determining resource capacity, performing dependency priority eviction, triggering asynchronous preloading, and reserving cache resources for low-intensity core components; S4: Respond to user actions and trigger feedback loops, including loading service combinations according to dependency structure, recording loading integrity status, updating popularity and predicted weights based on feedback, and dynamically adjusting path verification strictness.

[0012] Preferably, in step S1, the cache acceleration unit is integrated in the form of an expansion card, the non-volatile memory supports high endurance read and write, the programmable controller is an on-chip system, and maintains a cache slot mapping table; the dependency graph is constructed by a graph traversal algorithm and stored in the internal register of the acceleration unit.

[0013] Preferably, in step S2, the behavior predictor identifies key dependent nodes of candidate combinations. If the user operation does not cover them, its prediction confidence is reduced. The cache controller queries the popularity of each component, marks low-popularity core components, and triggers resource reservation.

[0014] Preferably, in step S3, when the cache space is insufficient, the cache controller sorts the components by popularity, dependency complexity, role relevance and component criticality; preloading reads missing components in batches and writes them into the corresponding cache slots, and then updates the index between components.

[0015] Preferably, in step S4, the cache controller records the loading status, including "full hit", "partial preload" or "dependency missing rollback"; the popularity monitoring agent updates the popularity score accordingly; the cache controller dynamically adjusts the strictness of the predicted path verification based on the frequency of the "dependency missing rollback" event.

[0016] The beneficial effects of this invention are: This invention constructs a structured dependency view within a service composition by loading a service composition registry and parsing its internal dependency graph. It also constructs a three-dimensional heat profile of role-based service composition dependencies and writes it into the multi-dimensional heat register array of the cache controller. This heat profile comprehensively considers user roles, service compositions, and internal component dimensions, achieving a more refined heat assessment and providing multi-dimensional basis for intelligent elimination and preloading decisions.

[0017] This invention introduces a behavior predictor during the user configuration process, combining multimodal inputs (user roles, operation sequences) to accurately output candidate service combinations and parse the internal dependency structure of each candidate combination. This proactive approach optimizes the possibility of cache loading.

[0018] Meanwhile, this invention proposes a prediction path credibility verification mechanism. By checking the coverage of key dependency nodes of user operations and candidate combinations, it effectively reduces the priority of invalid predictions and avoids preloading incomplete or inconsistent service combinations, thereby improving the effectiveness of caching. This invention also implements a heat monitoring agent to query the multi-dimensional heat of combinations and their components. Combined with a low-heat core component early warning mechanism, it can promptly identify and protect components that are not frequently called but are crucial to the business, preventing them from being mistakenly eliminated. Attached Figure Description

[0019] Figure 1 This is a block diagram of the overall structure of the service platform of the present invention; Figure 2 This is a block diagram of the internal structure of the service configuration caching acceleration unit of the present invention; Figure 3 This is a schematic diagram of the logical structure of the internal dependency graph of the service registry of the present invention; Figure 4 This is a flowchart illustrating the application method of the service platform of the present invention; Figure 5 This is a schematic diagram illustrating the steps of deploying a dedicated caching acceleration unit and injecting service composition dependency metadata according to the present invention. Figure 6 This is a schematic diagram illustrating the steps of triggering dependency-aware prediction and path verification during user configuration in this invention. Figure 7 This is a schematic diagram illustrating the steps of cache resource planning and loading driven by the execution dependency structure of the present invention. Figure 8 This is a schematic diagram illustrating the steps of responding to user operations and triggering a structured feedback loop according to the present invention. Detailed Implementation

[0020] In the description of this invention, it should also be noted that, unless otherwise explicitly specified and limited, the terms "set," "install," "connect," and "link" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0021] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention. Example 1

[0022] This embodiment discloses a service platform based on multimodal automated configuration, referring to... Figures 1-3 The service platform includes: a Service Configuration Cache Acceleration Unit (SCCAU), a behavior predictor, a popularity monitoring agent, a cache controller, and a service registry. The Service Configuration Cache Acceleration Unit is configured on the server motherboard expansion interface of the service platform and includes a non-volatile memory and a programmable controller. The non-volatile memory is logically divided into multiple main cache slots, and each main cache slot can be further divided into multiple sub-cache slots. The main and sub-cache slots are used to store independent service components and their dependent resources in the service portfolio. The service registry stores metadata for all registered service portfolios and dependency graphs between services within each service portfolio. The behavior predictor is configured to infer the service portfolios that a user may build based on the current user role and operation sequence, and output a list of candidate service portfolios. The popularity monitoring agent is configured to query the multi-dimensional popularity of a specific service portfolio and its internal components under the current user role. The cache controller is configured to receive the dependency graph of the service portfolio, the multi-dimensional popularity of the components, and the prediction confidence as input, and dynamically plan the cache slot allocation and loading strategy based on the dependency graph.

[0023] In a preferred embodiment of this invention, the Service Configuration Cache Acceleration Unit (SCCAU) integrates a dedicated data transmission interface and high-speed processing logic. The non-volatile memory is implemented using 3D XPoint memory technology, which offers high durability and high read / write speeds, and has a capacity of at least 2TB to meet the storage requirements of large-scale service components. The programmable controller is a hybrid architecture integrating an ASIC (Application-Specific Integrated Circuit) and a high-performance FPGA (Field-Programmable Gate Array). The ASIC is responsible for accelerating the core data path, while the FPGA is used to implement flexible programmable cache management logic and hardware acceleration of prediction algorithms. The programmable controller integrates multiple dedicated register arrays, including a dependency graph storage register, a multi-dimensional hot register array, and a cache slot mapping table register. These register arrays enable fast access and management of cached data and metadata. The main cache slots and sub-cache slots in the non-volatile memory employ a page-addressing and block-level allocation mechanism. Each main cache slot is allocated a fixed-size physical storage area, such as 64MB, while each sub-cache slot is dynamically allocated according to the actual size of the service storage component, with a granularity refined to 4KB. The programmable controller is capable of performing direct memory access (DMA) operations on the main cache slot and the sub-cache slot to achieve ultra-low latency data loading and storage.

[0024] In a preferred embodiment of this invention, the service registry stores service composition metadata including: a unique identifier (ID) for the service composition, version information, a list of core services, a list of auxiliary services, a list of shared resources, and the minimum resource requirements (such as CPU core count, memory usage, and network bandwidth requirements) and key dependency flags for each service component. Internally, the service registry maintains a directed acyclic graph (DAG) structure to represent the dependencies within the service composition. Each node in the DAG represents a service component or shared resource, and each directed edge represents a service call, data flow, or logical dependency. The service registry provides the service composition metadata and dependency graph to the behavior predictor and the cache controller. Upon platform startup or service composition update, the service registry proactively pushes the updated dependency graph information to the cache controller via an event notification mechanism and stores it in the dependency graph storage register within the programmable controller to ensure data synchronization and low access latency.

[0025] In a preferred embodiment of this invention, the behavior predictor is implemented using a sequence prediction model based on the Transformer architecture. The prediction model accepts multimodal input, including: the current user session ID, user role identifier, historical operation sequence (the past N clicks, inputs, and page jump records), current timestamp, current system load status, and the user's department or business line. The user role identifier is, for example, "cross-border express mail inspector" or "bonded zone import declarant." The operation sequence is obtained by encoding the user interface interaction event stream. The prediction model analyzes the multimodal input and outputs an ordered list of candidate service combinations. Each candidate service combination is accompanied by a prediction confidence score, which represents the probability that the user will select that service combination in the current context. The prediction confidence score is calculated based on the model's softmax output and calibrated to reflect the actual probability distribution. The behavior predictor periodically obtains data from the platform's user behavior log system and performs online learning or incremental training to adapt to dynamic changes in user behavior patterns.

[0026] In a preferred embodiment of this example, the heat monitoring agent collects call events of service compositions and their internal components in real time by subscribing to telemetry data streams and business call logs within the platform. The heat monitoring agent uses a sliding time window (e.g., the past 24 hours or the past 7 days) and an exponentially decaying moving average algorithm to calculate a multidimensional heat score for each "user role-service composition-internal service component" triplet. The multidimensional heat score comprehensively considers factors such as call frequency, recent call time, average response time, and failure rate. Specifically, for call frequency, an exponential decay factor λ is used to make recent calls contribute more to the heat score. The heat monitoring agent periodically writes the updated multidimensional heat scores in batches into the multidimensional heat register array inside the programmable controller of the service configuration cache acceleration unit. The multidimensional heat register array uses a three-dimensional hash table structure to achieve O(1) time complexity lookup for the heat score of a specific triplet. If the heat score of a core component is found to be lower than a preset threshold, the heat monitoring agent will send a low-heat core component warning signal to the cache controller, triggering a subsequent resource reservation mechanism. Example 2

[0027] This embodiment discloses an application method for a service platform based on multimodal automated configuration, referring to... Figures 4-8 The method includes the following steps: Step S1: Deploy a dedicated cache acceleration unit and inject service composition dependency metadata.

[0028] During the platform startup phase, hardware resource deployment and service composition structured metadata loading are completed, laying the foundation for dependency-aware caching.

[0029] S101: Integrate Service Configuration Cache Acceleration Unit (SCCAU) and divide it into multi-level cache slots.

[0030] A dedicated service configuration cache acceleration module is mounted on the server motherboard expansion interface of the service platform. The cache acceleration module includes a non-volatile memory and a programmable controller. The non-volatile memory is logically divided into multiple main cache slots, and each main cache slot can be further divided into multiple sub-cache slots. The main cache slots and the sub-cache slots are used to store independent service components and their dependent resources in the service storage portfolio.

[0031] The programmable controller internally includes a multi-core RISC processor, a dedicated hardware acceleration unit (e.g., an FPGA programmable logic array for graph traversal algorithms), and a NAND flash memory controller interface for controlling read and write operations on the non-volatile memory. The logical address space of the non-volatile memory is precisely divided into 128 main cache slots, each logically corresponding to the root configuration of a service composition and its directly associated core components. Each main cache slot is further dynamically divided into up to 256 sub-cache slots, which are used to store auxiliary services, shared resources, and other fine-grained dependent components of the service composition. The programmable controller maintains a B+ tree-based memory mapping table for fast indexing of the physical addresses of the main cache slots and sub-cache slots, ensuring addressing operations are completed within milliseconds.

[0032] S102: Load the service composition registry and parse the internal dependency graph.

[0033] Metadata for all registered service combinations is read from the platform service registry of the service platform. For each service combination, the dependencies between its internal service components are parsed, and a structured dependency graph is generated. The dependency graph clearly identifies the calling relationships and data flows between the main service, sub-services, and shared resources (e.g., common user interface (UI) templates, business rule bases, and data model definitions).

[0034] The loading process specifically involves the cache controller periodically retrieving the latest service composition registration information from a distributed service registry. This registration information is transmitted as a metadata document in JSON or YAML format, containing the service composition's name, version, functional description, and a clear list of service components. Upon receiving the metadata document, the cache controller activates its internal dependency resolution engine. This engine employs a depth-first search (DFS) algorithm to traverse the component list of each service composition and constructs a directed acyclic graph (DAG) based on predefined dependency declarations. Nodes in the DAG represent service components, and edges represent dependencies. Each edge in the DAG also carries an attribute, such as "strong dependency," "weak dependency," or "data flow dependency," to distinguish different types of dependency strength. After resolution, the structured dependency graph is stored in compressed form in the dependency graph storage register within the programmable controller of the Service Configuration Cache Acceleration Unit (SCCAU), and is quickly looked up using a hash index that maps the service composition ID to its corresponding dependency graph data block.

[0035] S103: Construct a 3D heat map of the character combination and write it to the controller.

[0036] Based on historical call log data from the platform, call frequency statistics are performed according to three dimensions: user role, service composition, and internal service component. Based on the statistical results, an initial popularity score is generated for each "user role-service composition-internal service component" triplet, and this popularity score is written into the multi-dimensional popularity register array inside the programmable controller of the Service Configuration Cache Acceleration Unit (SCCAU).

[0037] The heat profile construction process specifically involves the heat monitoring agent continuously extracting user behavior events and API call logs from the platform's big data log processing system (e.g., a real-time stream processing system based on Apache Flink). The log data is parsed to extract user ID, role ID, timestamp, service composition ID, and the IDs of the internal service components involved. The heat monitoring agent maintains a distributed set of counters to aggregate these call events within a preset time window (e.g., refreshed hourly). For each unique triple (user role, service composition, internal service component), its heat score is calculated using a multi-factor weighted model combining call frequency, recent activity, and average processing time. For example, heat score = αlog(call frequency) + βexp(-Δt / τ) + γ(1 / average processing time), where α, β, and γ are weighting coefficients, Δt is the time interval since the last call, and τ is a time decay constant. The initial heat score is generated when the platform first starts or when a new service is launched, and is continuously updated incrementally based on the latest log data. The multidimensional popularity register array is logically organized into a sparse three-dimensional array structure within the programmable controller. The first dimension index is the user role hash value, the second dimension is the service composition ID hash value, and the third dimension is the internal service component ID hash value. Each unit stores the corresponding popularity score, thereby supporting efficient read and write operations.

[0038] Step S2: Trigger dependency-aware prediction and path verification during user configuration.

[0039] When a user begins low-code configuration, the service platform generates a prediction based on the user's operation context and performs structural integrity verification on the predicted service composition path.

[0040] S201: The behavior predictor combines the role context to output a combination of candidate services.

[0041] The behavior predictor identifies the current user's role and, combined with their historical action sequence (e.g., mouse click events, keyboard input, page navigation history), infers the possible service combinations the user might build and outputs a list of candidate service combinations. Each entry in the candidate service combination list contains a prediction confidence score.

[0042] The identification and inference process specifically involves the following steps: When a user performs interactive operations on the service platform's front-end interface (e.g., dragging components on a low-code development canvas, clicking function menus, or entering query keywords), the front-end application pushes these real-time interactive event streams to the behavior predictor. The behavior predictor first obtains the current user's unique identifier and associated role information (e.g., the "Cross-border E-commerce Business Manager" role obtained through a Role-Based Access Control (RBAC) system) from the user session manager. The behavior predictor's internal deep learning-based sequence model (e.g., a Transformer model with an attention mechanism) takes the user role information, the current interface's state vector (e.g., currently open modules, focused controls), and the encoded sequence of the N most recent historical operation events as input. By analyzing these multimodal features, the model predicts the service combination that the user is most likely to choose or construct next. The prediction result is output in the form of a probability distribution, which the behavior predictor transforms into a list of candidate service combinations sorted from high to low prediction confidence, for example, outputting the top 5 most likely service combinations and their corresponding confidence scores.

[0043] S202: Analyze the internal dependency structure of each candidate combination.

[0044] The service platform calls the service registry to obtain the complete internal dependency graph of the candidate service combination, and identifies the core services, auxiliary services and shared resource modules it contains, thereby clarifying the minimum complete unit required for cache loading.

[0045] The parsing process specifically involves the following steps: For each candidate service combination output by the behavior predictor, the cache controller sends a query request to the service registry to obtain the complete dependency graph of that service combination. The service registry responds to the request and returns detailed metadata for the service combination, including the directed acyclic graph (DAG) representation of its dependencies. Upon receiving the DAG, the cache controller performs rapid comparison and verification using its internally stored dependency graph storage register to ensure the accuracy of the dependency graph. The cache controller further traverses the DAG, classifying nodes into "core services" (e.g., identified by metadata, these services are indispensable components of the business process), "auxiliary services" (e.g., providing non-core but important functions such as logging and monitoring), and "shared resource modules" (e.g., common authentication libraries, internationalization resource files, public API interface definitions). Through this process, the cache controller can accurately determine the complete list of components required for a service combination to function fully and use it as the smallest complete unit set for subsequent cache loading operations.

[0046] S203: Perform confidence verification of the predicted path.

[0047] The behavior predictor checks whether the current user action covers the critical dependency nodes of the candidate service combination. If a critical dependency node is detected to be missing, the candidate service combination is marked as "incomplete path," and its priority in subsequent scheduling is reduced accordingly.

[0048] The verification process specifically involves the behavior predictor acquiring the complete dependency graph for each candidate service combination and identifying the "critical dependency nodes" within that combination. These critical dependency nodes are components or prerequisite operations essential for the correct functional implementation of the service combination. For example, in an "import / export customs declaration" service combination, the "document recognition module" and the "risk assessment engine" might be identified as critical dependency nodes. The behavior predictor tracks the user's current operation context and historical operation trajectory in real time. By comparing the user's real-time operation sequence with the expected operation path of the candidate service combination, the behavior predictor determines whether the user has triggered or explicitly selected the functions corresponding to these critical dependency nodes. For example, if the user has clicked the "document recognition" button on the interface and uploaded customs declaration documents, it is considered that the critical dependency node of the "document recognition module" has been overridden. If a key dependency node of a candidate service combination is found to be not covered by the current user's operation path (e.g., the user skips the necessary data input steps or selects an accessibility function that does not match the predicted path), the behavior predictor reduces the "predicted path confidence" of the candidate service combination to below a preset threshold and marks its internal state as "incomplete path". The marking result will serve as an important input to the cache controller scheduling process in step S205, affecting the cache priority of the candidate combination.

[0049] S204: Multidimensional popularity of the combination of popularity monitoring agent query and its components.

[0050] The service platform queries the overall popularity of the candidate service combination under the current user role, as well as the independent popularity of each service component within the candidate service combination, through the popularity monitoring agent. If the popularity of a core component is detected to be extremely low (for example, the component is a newly launched service or a key module that is not frequently called), the resource reservation mechanism in the subsequent S205 step is triggered.

[0051] The query process specifically involves the following steps: After the behavior predictor outputs a list of candidate service combinations and completes path credibility verification, the cache controller proactively initiates an asynchronous query request to the popularity monitoring agent. The query request carries the current user's role ID, the ID of each candidate service combination, and the IDs of all internal service components within each combination. Upon receiving the query request, the popularity monitoring agent immediately performs a high-speed lookup within the multi-dimensional popularity register array of the programmable controller in the Service Configuration Cache Acceleration Unit (SCCAU). The popularity monitoring agent quickly obtains the corresponding popularity score based on the three-dimensional index (user role ID, service combination ID, and service component ID). The popularity monitoring agent returns the overall popularity score for each candidate service combination (e.g., obtained by weighted averaging of the popularity scores of all its internal core components) and the independent popularity score for each core component. After receiving this popularity data, the cache controller will make a judgment: if a component marked as "core" has an independent popularity score lower than a preset "low popularity threshold" (for example, the frequency of calls in the last 24 hours is less than 10 times), the cache controller will set a "low popularity core component" flag for this core component and pass it as input to step S205 to trigger a special cache resource reservation logic to ensure that it will not be easily eliminated even if its popularity is low.

[0052] S205: The cache controller receives the dependency structure and multi-dimensional popularity, and starts the dependency-aware scheduling process.

[0053] The cache controller receives the dependency graph of the service composition, the multidimensional popularity of the components, and the prediction confidence as input. The cache controller initiates a refined cache planning process to guide subsequent cache resource allocation and data loading.

[0054] The startup process specifically involves the cache controller collecting the following key information after completing steps S202, S203, and S204: the complete dependency graph of each candidate service combination, its predicted path confidence, the overall popularity of the combination, and the independent popularity of each component within it (including the "low-popularity core component" flag). The cache controller inputs this multi-dimensional information into an internal scheduling engine based on a combination of heuristic rules and machine learning. The scheduling engine first reorders the candidate list, prioritizing service combinations with high prediction confidence, complete paths, and high overall popularity. Combinations with high prediction confidence but incomplete paths have their priority appropriately reduced. For combinations containing "low-popularity core components," the scheduling engine assigns a special "protection weight." The output of the scheduling engine is an optimized cache loading priority queue, containing each candidate service combination and its suggested caching strategy (e.g., "preload all dependencies," "preload only core dependencies," "trigger resource reservation," etc.). Based on this priority queue, the cache controller initiates the fine-grained cache resource planning and loading process in phase S3, thereby ensuring the dependency awareness and intelligence of cache operations.

[0055] Step S3: Perform dependency-driven cache resource planning and loading.

[0056] The cache controller dynamically plans cache slot allocation and data loading strategies based on the service composition dependency structure.

[0057] S301: Evaluate the cache load integrity requirements of candidate combinations.

[0058] The cache controller determines the minimum set of cache units required for the candidate service combination based on the dependency graph. The set includes the main service configuration, sub-service metadata, shared UI templates, etc., to ensure that the service combination can run independently and completely after loading.

[0059] The evaluation process specifically involves the cache controller retrieving the complete directed acyclic graph (DAG) for each candidate service composition from its internal dependency graph storage register. The cache controller traverses the DAG, identifying all directly and indirectly dependent service components and shared resources. For each identified component, the cache controller queries its metadata (obtained and stored from step S102) to determine its specific physical resource requirements, such as the component's executable binary size, configuration file size, required static resource file size (e.g., images, stylesheets), and the size of any related database schema or business rule set. The cache controller calculates the total size of all these dependent components as the "completeness cache requirement space" for the service composition. Furthermore, the cache controller also evaluates whether the service composition contains any critical resources marked with "strong dependency," which are considered elements that must be loaded once to ensure the complete operation of the service composition. The "minimum cache unit set" does not only refer to the component itself but also includes all preprocessed or pre-linked data required to ensure the component can be quickly initialized and executed.

[0060] S302: Check if each component already exists in the cache.

[0061] The cache controller compares each service component ID in the dependency graph with the binding ID of the cache slot within the Service Configuration Cache Acceleration Unit (SCCAU). If all required components are hit in the cache, the combination is marked as a "full hit"; if only some components are hit, a list of missing components is recorded.

[0062] The checking process specifically involves the cache controller maintaining a real-time updated cache slot mapping table, which records the service component ID and its version number stored in each active cache slot (main slot or sub-slot). For components in the "minimum cache unit set" of each service combination determined in step S301, the cache controller queries the cache slot mapping table using a fast lookup mechanism based on a Bloom filter or hash table. The lookup operation is performed at the hardware level by the programmable controller, resulting in extremely low latency. If a component's ID and version number find a corresponding active cache slot in the mapping table, the component is considered "hit." The cache controller also records the hit status of each component. After traversing all dependent components, if all components have hit, the service combination is marked as "fully hit." If one or more components are found to be hit, the IDs of these hit components are collected and stored as a "missing component list," and the service combination is marked as "partially hit." The hit status and the missing component list are key inputs for subsequent cache loading decisions.

[0063] S303: Determine if the cached resources are sufficient to accommodate the complete combination.

[0064] The cache controller calculates the total storage space required for the missing component list and checks the currently available free cache slot capacity in the Service Configuration Cache Acceleration Unit (SCCAU). If the free capacity is insufficient to accommodate the total space required for the missing components, the cache controller proceeds to the resource reservation and eviction process in step S304.

[0065] The specific determination process involves the cache controller obtaining the precise size of each missing component from the service registry or local metadata cache based on the "missing component list" generated in step S302. The cache controller sums the sizes of all missing components to obtain the "additional space requirement" needed for the complete loading of the service composition. Simultaneously, the cache controller monitors in real-time the total amount of free physical storage space in the non-volatile memory of the Service Configuration Cache Acceleration Unit (SCCAU), as well as the capacity of each available primary and secondary cache slot. The cache controller compares the "additional space requirement" with the current "available free capacity." To avoid cache fragmentation, the cache controller also considers the continuity of available free space. If the total free space is sufficient, but there is not enough contiguous space to accommodate a large missing component, it is also considered insufficient space. If the available free capacity is less than the additional space requirement, or cannot provide enough contiguous physical blocks, the cache controller triggers a cache eviction policy, proceeding to step S304 to release necessary space.

[0066] S304: Perform priority-driven eviction arbitration.

[0067] The cache controller prioritizes eviction of low-value service combinations that are irrelevant to the current user's role and have simple dependency structures, based on a preset eviction policy. For service combinations with high dependency complexity (e.g., containing more than five core service components), the cache controller will still give them a higher retention priority even if their current popularity is slightly lower, in order to avoid service startup delays caused by frequent rebuilds.

[0068] Specifically, the eviction arbitration involves the cache controller initiating a multi-dimensional eviction algorithm when step S303 determines that cache space is insufficient. The algorithm first constructs a candidate list of cache entries to be evicted. For each service combination in the list, the cache controller calculates its "eviction score." The formula for calculating the eviction score is, for example: EvictionScore = W1(1-Popularity Score) + W2 Dependency Complexity + W3(1-Role Relevance) + W4 Recent Access Time - Decay Factor + W5(1-Criticality Index). Here, W1-W5 are weighting coefficients. "Dependency Complexity" is quantified by analyzing the number of nodes, edges, and longest path length in the service combination's dependency graph. "Role Relevance" indicates the degree of match between the combination and the currently active user's role. The "Criticality Index" originates from the identification of core components in S202. The cache controller sorts the candidate list from highest to lowest eviction score and prioritizes eviction of the service combination with the highest score until sufficient space is released. For service combinations marked as "high dependency complexity" (e.g., with a dependency graph depth greater than 3 or more nodes than 10), even if their popularity is slightly lower, their eviction score will be reduced by assigning a low W2 dependency complexity value, thereby ensuring their cache residency time to some extent.

[0069] S305: Triggers asynchronous preloading of dependency integrity.

[0070] The cache controller initiates a batch read request to the backend storage system, loading all service components in the missing component list at once. After the data is returned, the cache controller writes the component data into the main cache slot and its corresponding sub-cache slot of the Service Configuration Cache Acceleration Unit (SCCAU) according to the dependency structure of the service composition, and establishes index associations between components.

[0071] The preloading process specifically involves the following steps: After space allocation is completed (if eviction is required), the cache controller generates an optimized batch read command based on the "missing component list" determined in step S302. This batch read command is sent to the backend distributed storage system (e.g., Ceph or Hadoop HDFS-based object storage) via the high-speed data transmission interface of the Service Configuration Cache Acceleration Unit (SCCAU) (e.g., NVMe over Fabrics (NVMe-oF) protocol). The batch read request is designed to retrieve all missing component data blocks at once to minimize I / O round-trip time. The backend storage system processes these requests in parallel and streams the data back to the Service Configuration Cache Acceleration Unit (SCCAU). Upon data arrival, the DMA (Direct Memory Access) engine within the programmable controller directly writes the data to the pre-allocated non-volatile storage in the main and sub-cache slots. After writing, the cache controller updates its internal cache slot mapping table, precisely binding the ID of the newly loaded component to its physical storage location. Meanwhile, the cache controller will also establish logical indexes and internal pointers for these newly loaded sub-components in the main cache slot metadata of the service composition. For example, it can use a hash table or linked list structure to represent the logical relationships between components, ensuring that the components can be quickly assembled in the order of dependencies when the service starts.

[0072] S306: Reserve cache resources for newly launched or low-popularity core components.

[0073] If a core service component (i.e., a component that is critical to the complete operation of the service composition but has a low popularity score due to being newly launched or not frequently triggered) is detected as a "low-popularity core component" in step S204, the cache controller will reserve a dedicated sub-cache slot for it and set a longer retention period for this sub-cache slot or exempt it from the regular eviction policy to prevent it from being accidentally evicted from the cache due to low popularity, which would cause the relevant service composition to fail to start.

[0074] Specifically, the resource reservation mechanism works as follows: when step S204 identifies a "low-hot core component" flag and passes it to the cache controller, the cache controller allocates a dedicated sub-cache slot for that specific core component in the non-volatile memory during the write phase of step S305. This dedicated sub-cache slot is marked as "Reserved" in the cache slot mapping table, and its associated metadata records a special "Reservation Policy ID." The Reservation Policy ID instructs the programmable controller to ignore or lower the eviction priority of this sub-cache slot when performing regular cache eviction arbitration (S304). For example, a TTL (TimeToLive) value much higher than that of ordinary components can be set, or it can be removed from the LRU / LFU queue. Furthermore, the cache controller can periodically perform "heartbeat checks" on these reserved low-hot core components to confirm they are still valid and refresh or verify their integrity if necessary. This aims to balance the effective utilization of cache resources with the reliability of critical services, ensuring that even low-frequency but important services can respond promptly.

[0075] Step S4: Respond to user actions and trigger a structured feedback loop.

[0076] After the user confirms the service combination, the service platform not only loads the service quickly, but also triggers a differentiated feedback mechanism based on dependency integrity.

[0077] S401: Load the complete service composition from the cache according to the dependency structure.

[0078] The service platform reads the root configuration information of the service combination through the address of the main cache slot. Following the index information recorded in the root configuration, the service platform sequentially loads all service components in the sub-caches corresponding to the main cache slot. The front-end application completes the user interface (UI) rendering and business logic binding of the complete service combination within 100 milliseconds.

[0079] The loading process is as follows: after the user confirms the selection of a service combination on the front-end interface, the front-end application sends a loading request to the service platform. Upon receiving the loading request, the cache controller first looks up the corresponding "primary cache slot" address in the cache slot mapping table within the Service Configuration Cache Acceleration Unit (SCCAU) using the service combination ID. Once the primary cache slot is located, the programmable controller directly reads the root configuration data of the service combination from non-volatile memory via a DMA engine. The root configuration data contains a list of logical indices or physical addresses pointing to all sub-cache slots, which store all dependent components of the service combination. Based on this list, the programmable controller reads the data of all relevant sub-components from non-volatile memory in a parallel or pipelined manner and transmits it to the server's system memory via a high-speed internal bus. The core runtime environment of the service platform (e.g., a containerized microservice architecture) receives this loaded component data and completes service instantiation, configuration loading, and dependency injection in a very short time. For the front-end application, these pre-loaded UI component templates and business logic modules are rapidly assembled into the browser or client's rendering engine, providing a seamless user experience.

[0080] S402: Record the dependency integrity status of this load.

[0081] The service platform records the dependency integrity status of this service combination loading, including: whether "full hit" is achieved, whether "partial preloading" is triggered, and whether there is a "dependency missing rollback" situation. Based on the status, a corresponding feedback type is generated.

[0082] The recording process specifically involves the following: after the service composition loading is completed in step S401, the cache controller generates a loading report based on the execution results of steps S302 and S305. The loading report records in detail: 1. Full Hit Status: If step S302 determines that all dependent components are found in the cache, it is marked as a "full hit".

[0083] 2. Partial Preload Status: If step S302 finds that some components are missing, but step S305 successfully fills in all missing components through the asynchronous preload mechanism, it is marked as "partial preload".

[0084] 3. Dependency Missing Rollback Status: If step S302 finds that some components are missing, and step S305 fails to preload all missing components in a timely or complete manner for some reason (e.g., backend storage system failure, high network latency, cache space allocation failure, etc.), causing the service composition to need to be synchronously loaded from the original storage medium at startup, or even fail to start, it is marked as "Dependency Missing Rollback".

[0085] The cache controller encapsulates these status information along with related metadata such as timestamps, user IDs, and service composition IDs into a structured feedback event. This feedback event is sent via a message queue (e.g., a Kafka topic) to the background log and monitoring system, the popularity monitoring agent, and the behavior predictor, forming a closed-loop feedback chain.

[0086] S403: Update multidimensional popularity and dependency weights based on feedback type.

[0087] If the record is "Full Hit", the popularity score of the service composition and all its components under the current user role will be increased. If the record is "Partial Preloading", the popularity score of the missing components preloaded this time will be increased, and the behavior predictor's coverage detection mechanism for dependency paths will be optimized. If the record is "Dependency Missing Rollback", the service composition will be marked as a "High Dependency Risk Combination", and its cache integrity will be prioritized in subsequent scheduling.

[0088] The update process specifically involves the following: after receiving the feedback event generated in step S402, the heat monitoring agent executes a differentiated heat update strategy based on the feedback type. 1. "Full Hit" Feedback: The popularity monitoring agent will significantly improve the popularity score of the service portfolio and all its internal core components under the current user role. The improvement is achieved using a preset multiplicative factor (e.g., 1.2x), and its most recent access time is updated, allowing the portfolio to achieve a longer dwell time in the future when popularity declines.

[0089] 2. "Partial Preloading" Feedback: The popularity monitoring agent prioritizes increasing the popularity scores of missing components preloaded in this operation to accelerate their future cache hit rate. Simultaneously, the popularity monitoring agent sends a signal to the behavior predictor, indicating the specific component information preloaded. The behavior predictor uses this information to adjust its internal model parameters, making the predicted path coverage detection for these components more stringent in similar user contexts, or adjusting their weights in dependency paths, thereby improving the completeness of future predicted paths.

[0090] 3. "Dependency Missing Rollback" Feedback: The popularity monitoring agent will mark the service composition as "high dependency risk" and assign an additional "risk weight" to it. During the S304 elimination arbitration process, compositions with a "risk weight" will be given a higher retention priority, even if their popularity is not high, and will be preferentially retained in the cache to avoid further missing rollbacks. Simultaneously, the popularity monitoring agent will trigger an alarm mechanism to notify the system administrator to check the dependency configuration or backend storage performance of the service composition.

[0091] S404: Dynamically adjust the strictness of dependency integrity checks.

[0092] The cache controller automatically adjusts the stringency of the predicted path credibility verification in step S203 based on the frequency of "dependency missing fallback" events in recent operations. If "dependency missing fallback" events occur frequently, the coverage requirements for critical dependency nodes are increased; if the system is running stably, the verification conditions are appropriately relaxed.

[0093] The adjustment process specifically involves the cache controller maintaining a sliding window statistician to continuously track the number of "dependency missing fallback" events occurring within a recent period (e.g., the past hour or the last 100 service load operations). The statistician calculates the frequency or proportion of "dependency missing fallbacks." The cache controller then compares this frequency with a preset threshold.

[0094] 1. If the frequency of "dependency missing fallback" exceeds the "high-risk threshold": The cache controller will send an instruction to the behavior predictor, instructing it to increase the stringency of the "predicted path confidence verification" in step S203. Specific adjustment parameters include: increasing the weight of key dependency nodes, increasing the minimum requirement for path coverage, or lowering the prediction confidence threshold. This aims to force the behavior predictor to be more cautious when generating candidate combinations or to be more rigorous in verification, thereby reducing the risk of incomplete service combinations being recommended and loaded.

[0095] 2. If the frequency of "dependency missing fallback" is lower than the "stability threshold": The cache controller will moderately reduce the stringency of the prediction path confidence verification in step S203. For example, the coverage requirements for certain non-core critical nodes can be relaxed, or predictions with lower confidence can be allowed to pass verification. This aims to improve the flexibility and coverage of the prediction system without excessively consuming system resources.

[0096] The dynamic adjustment mechanism, through a feedback loop, enables the service platform to adaptively adjust its prediction and caching strategies based on the robustness of the actual operating environment, in order to achieve the best balance between performance and reliability.

[0097] Step S5: Achieve long-term steady-state optimization of the dependency-aware caching system.

[0098] The steps S1 to S4 described above are nested in a loop during the operation of the service platform, forming an adaptive caching system that supports the composition of structured services, thereby achieving long-term steady-state optimization.

[0099] S501: Cached content evolves in tandem with dependency complexity and role popularity.

[0100] High-frequency and complex service combinations (e.g., the "RCEP Origin Intelligent Document Verification" service combination, which involves multi-party data collaboration, complex rule judgment, and multi-document processing) can reside in the cache of the Service Configuration Cache Acceleration Unit (SCCAU) for extended periods. In contrast, low-frequency and simple service combinations are loaded on demand, and their residence time in the cache is dynamically adjusted based on actual usage and eviction policies, resulting in a more rational and efficient allocation of cache resources. This collaborative evolution mechanism ensures that cached content remains highly consistent with the platform's core business needs and most active user scenarios, preventing cache "pollution" and the long-term occupation of invalid data.

[0101] S502: Predictive models learn the dependency building patterns of service compositions step by step.

[0102] The behavior prediction model, by continuously receiving feedback information generated in step S403 (especially feedback on "partial preloading" and "dependency missing fallback"), can progressively learn the specific dependency path sequence and triggering patterns of key components when the user constructs a service composition. This learning process employs techniques such as reinforcement learning or online incremental learning to continuously optimize the model's weights and internal states. Over time, the prediction model can not only accurately predict the service composition ultimately chosen by the user, but also improve the completeness and accuracy of predicting the dependency construction paths followed by the user during interaction. This provides a more accurate basis for path credibility verification in step S203, further reducing invalid predictions and incomplete loading.

[0103] S503: Service portfolio launch success rate significantly improved.

[0104] By employing the dependency-aware caching and prediction mechanism proposed in this invention, the probability of a service composition being fully loaded from the cache and successfully launched after being selected by the user is significantly increased. This improvement directly enhances the user experience, reduces the risk of business interruption, and strengthens the robustness of the entire service platform. The increased success rate is due to the invention's ability to pre-identify all dependencies and ensure they are available before service startup, whether through hitting existing caches or asynchronous preloading.

[0105] S504: Improves both hardware cache resource utilization efficiency and service integrity.

[0106] This invention effectively avoids the invalid cache usage caused by traditional caching mechanisms that "only load the main service but miss key sub-services" through a dependency-aware loading strategy. Traditional solutions often only preload the core entry component, while its deep dependencies are loaded on demand at runtime, resulting in some cached data being in a "half-finished" state. This invention ensures that each time a complete and usable service combination is loaded into the cache, significantly improving the effectiveness of cache hit operations.

[0107] The above are merely preferred embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. A service platform based on multi-modal automation configuration, characterized in that, include: The service configuration cache acceleration unit is configured on the server motherboard expansion interface and includes non-volatile memory and a programmable controller; The non-volatile storage is divided into multiple main cache slots, and each main cache slot can be further divided into multiple sub-cache slots for storing independent service components and their dependent resources in the storage service portfolio. The service registry is used to store metadata and internal dependency graphs of registered service combinations. A behavior predictor is used to combine user roles and action sequences to output a list of candidate service combinations; A popularity monitoring agent is used to query the multi-dimensional popularity of service combinations and their components under the current user role. The cache controller receives the dependency graph, multidimensional popularity, and prediction confidence, and dynamically plans the cache loading strategy based on the dependency structure.

2. The service platform of claim 1, wherein, The service configuration cache acceleration unit is connected to the main processor via a dedicated high-speed interface; the non-volatile memory adopts high read / write speed non-volatile memory technology; the programmable controller is a hybrid architecture of application-specific integrated circuit and field-programmable gate array, and the integrated register array is used to store dependency graph, hot data and cache mapping; the main cache slot and sub-cache slot support dynamic allocation, and the programmable controller supports direct memory access to achieve low-latency loading.

3. The service platform of claim 1, wherein, The service registry stores service composition metadata including unique identifiers, version information, a list of service components, and key dependency flags; the dependency graph adopts a directed acyclic graph structure, where nodes represent service components or shared resources, and edges represent calls or data dependencies; the service registry provides the dependency graph to the behavior predictor and cache controller through a standard interface, and actively pushes changes when services are updated.

4. The service platform of claim 1, wherein, The behavior predictor employs a sequence prediction model, with inputs including user roles, historical operation sequences, and system status, and outputs a list of candidate service combinations and prediction confidence. The model is incrementally trained based on user behavior logs.

5. The service platform of claim 1, wherein, The heat monitoring agent calculates a multi-dimensional heat score for the "user role-service composition-component" triple based on service call logs, taking into account call frequency and time decay; the heat score is periodically written to the register of the cache acceleration unit; if the heat of the core component is lower than the threshold, an alert is sent to the cache controller.

6. An application method of a service platform based on multi-modal automation configuration, applicable to the service platform as claimed in any one of claims 1-5, characterized in that, include: S1: Deploy the cache acceleration unit and inject dependency metadata, including dividing the main cache slot and sub-cache slot, parsing the service composition dependency graph, building a multi-dimensional heat profile and writing it to the controller; S2: Dependency-aware prediction is triggered during user configuration, including outputting candidate combinations from the behavior predictor, parsing their dependency structure, verifying the completeness of the prediction path, querying multidimensional popularity, and starting dependency-aware scheduling. S3: Perform dependency-driven cache loading, including evaluating loading integrity requirements, checking component cache status, determining resource capacity, performing dependency priority eviction, triggering asynchronous preloading, and reserving cache resources for low-intensity core components; S4: Respond to user actions and trigger feedback loops, including loading service combinations according to dependency structure, recording loading integrity status, updating popularity and predicted weights based on feedback, and dynamically adjusting path verification strictness.

7. The method of claim 6, wherein the step of applying is performed by a user. In step S1, the cache acceleration unit is integrated as an expansion card, the non-volatile memory supports high endurance read and write, the programmable controller is an on-chip system, and maintains a cache slot mapping table; the dependency graph is constructed by a graph traversal algorithm and stored in the internal register of the acceleration unit.

8. The method of claim 6, wherein the step of applying is performed by a user. In step S2, the behavior predictor identifies key dependent nodes of candidate combinations. If the user operation does not cover them, the prediction confidence is reduced. The cache controller queries the popularity of each component, marks low-popularity core components, and triggers resource reservation.

9. The method of claim 6, wherein the step of applying is performed by a user. In step S3, when the cache space is insufficient, the cache controller sorts the components by popularity, dependency complexity, role relevance and component criticality; preloading reads missing components in batches and writes them into the corresponding cache slots, and then updates the index between components.

10. The use according to claim 6, characterized in that, In step S4, the cache controller records the loading status, including "full hit", "partial preload" or "dependency missing rollback"; the popularity monitoring agent updates the popularity score accordingly; the cache controller dynamically adjusts the strictness of the predicted path verification based on the frequency of the "dependency missing rollback" event.

Images