Verifiable data processing method, device and system for online inference

Abstract

This invention discloses a verifiable data processing method, apparatus, and system for online reasoning. The method includes pre-configuring an evidence collection bypass module, an evidence bus, and an evidence repository. The evidence collection bypass module triggers abnormal events based on evidence prompts during the reasoning process. The module determines a time window including the trigger time, creates an event header, generates an event summary, and transmits it to the evidence repository via the evidence bus. The event summary includes a decision trajectory segment and a calculation specification segment at the trigger time. The module collects the full text of evidence within the time window, divides it into multiple evidence blocks, and configures corresponding block indexes. After transmitting the block indexes and evidence blocks sequentially to the evidence repository via the evidence bus, it generates an integrity verification field and sends a sealing identifier. Upon receiving the sealing identifier, the evidence repository performs integrity verification on the evidence package. If the verification passes, the evidence package is modified to a sealed state. This invention enables verifiable evidence recording, chained sealing, and playback processing of abnormal event data during online reasoning.

Description

Technical Field

[0001] This invention relates to the fields of data processing and artificial intelligence, and in particular to a verifiable data processing method, apparatus and system for online reasoning. Background Technology

[0002] With the widespread application of AI inference platforms, the stability of online services faces severe challenges. Common types of incidents that occur after deployment include: output drift caused by model version or routing changes, implicit degradation of model performance due to feature or dependency changes, and a surge in abnormal request volume caused by abrupt changes in data distribution. In incident debriefing, two core principles are typically required: "replayability" and "verification." This means not only being able to reproduce the same incident results in a controlled environment, but also being able to prove "what happened at the time (when the incident occurred), what version was used, what the input was, and whether the process was tampered with."

[0003] Currently, commonly used incident review methods in the industry typically include: utilizing online log systems or trace / span technologies, combined with monitoring metrics for alerts; collecting and maintaining request and response data for offline replay; locating incidents through version tagging and canary release records; and temporarily capturing container images, configuration files, and runtime parameters after an incident to attempt to reproduce the problem. However, existing incident review solutions have the following significant shortcomings.

[0004] (1) Incomplete evidence collection and inability to reconstruct the scene: Current solutions typically only record logs, link tracing information, or save input requests, lacking key contextual elements relied upon during the inference process, such as: feature version number, model weight version, word segmenter or post-processing module version, dynamic routing or grayscale selection results, runtime dependencies (such as CUDA / cuDNN / driver version), key runtime configurations (batch size, temperature parameters, top-k values, quantization parameters), and model-side cache status (such as KV-Cache / Embedding Cache). In actual online scenarios, incidents are often caused by minor changes in configuration, version, or routing. In such cases, the root cause is not an input error, but rather a change in the execution environment and path. Such problems cannot be reproduced based solely on input data, leading to a reliance on manual guessing during the debriefing process, making it difficult to repeatedly verify conclusions and forming a complete evidence loop.

[0005] (2) Difficulty in ensuring the authenticity of evidence: Most existing log systems or object storage systems allow data to be overwritten, supplemented, or spliced. Even with append-only writing, there is still a lack of strong constraints on the "order and correlation of events". Specifically, logs may be lost due to cleanup, rolling, or sampling strategies; evidence fragments of the same incident are scattered across multiple independent systems such as logs, metrics, feature repositories, and publishing systems, making it difficult to prove cross-system data consistency; "explanatory records" appended after an incident cannot effectively distinguish whether they were originally generated or added later. This leads to insufficient credibility of evidence in external audits, compliance checks, or liability arbitration, and is also prone to disputes during internal reviews.

[0006] (3) Uncontrollable performance overhead: Saving all context data in its entirety will lead to a sharp increase in network bandwidth and storage costs, and may increase request tail latency; while adopting a sampling saving strategy carries the risk that key samples of the incident may not be selected, resulting in the loss of key evidence. Especially when the incident is accompanied by a surge in traffic or amplification of long-tail latency, any "synchronous writing to large objects" solution may further deteriorate the stability of online services. This often forces the platform to weigh "evidence integrity" against "online service stability", and the platform is forced to choose between "sufficient evidence" and "online stability", making it difficult for existing solutions to operate continuously in the long term.

[0007] (4) The boundaries of the accident are unclear and the evidence cannot be aligned and compared: Most systems only record the time point when the alarm is triggered, and lack a fixed time window definition before and after the accident. This results in different recording durations for different accidents, making it difficult to perform batch statistics, threshold verification and horizontal alignment comparison, and even more difficult to support automated accident clustering and root cause analysis.

[0008] (5) Difficulty in cross-layer correlation: Currently, it mainly relies on manual experience, using methods such as string concatenation to trace the version release situation on the day the incident occurred. There is a lack of a unified structured "causal indexing mechanism". The incident cannot be structurally bound to "version / route / release batch / instance". Specifically, it is impossible to strongly bind the event with key elements such as model hash, feature hash, runtime hash, route digest, release version ID, and instance ID. This leads to a long time-consuming incident location, and the root cause analysis relies too much on personal experience, making it difficult to achieve large-scale and automated analysis.

[0009] (6) Handling actions not included in the evidence system: The measures and repair actions taken during the incident handling process are not traceable, such as version rollback, threshold adjustment, feature switch switching, service degradation, etc., and are usually only recorded in work orders or instant messaging tools, which are separate from the incident evidence itself. This makes it impossible to effectively trace "why the action was taken", "what the scope of the action was", and "what release batch the action corresponded to". As a result, it not only makes subsequent accountability, auditing and review difficult, but also makes it impossible to directly reuse the verified handling strategies when similar incidents occur again.

[0010] The disclosure of the above background information is only for the purpose of assisting in understanding the concept and technical solution of this application, and does not necessarily provide technical instruction. Summary of the Invention

[0011] The purpose of this invention is to provide a verifiable data processing method, apparatus and system for online reasoning, which can perform verifiable evidence recording, chain-based sealing and playback processing of data on abnormal events during online reasoning.

[0012] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0013] A verifiable data processing method for online reasoning includes the following steps:

[0014] A bypass module for evidence collection, an evidence bus, and an evidence storage are pre-configured. The bypass module and the evidence storage are connected through the evidence bus, which is independent of the inference link.

[0015] The evidence-gathering bypass module determines whether an abnormal event has been triggered based on evidence prompts during the reasoning process. The evidence prompts include decision trajectory segments and calculation specification segments. If an abnormal event is triggered, the evidence-gathering bypass module performs the following operations:

[0016] Determine the trigger time of the abnormal event and a time window including the trigger time, and create an event header, the event header including event ID, inference request ID, trigger time and time window;

[0017] An event summary is generated and transmitted to the evidence repository via the evidence bus. The event summary includes the event header, the decision trajectory segment at the trigger time, and the calculation specification segment.

[0018] Collect the full text of the evidence corresponding to the time window, divide the full text of the evidence into multiple evidence blocks, configure a corresponding block index for the evidence block, and the block index includes the event ID, block ID and block hash corresponding to each evidence block;

[0019] First, each of the block indexes is transmitted to the evidence repository via the evidence bus. Then, each evidence block is transmitted to the evidence repository to obtain a structured evidence package. After all evidence blocks have been transmitted to the evidence repository, an integrity verification field is generated and an archiving identifier is sent to the evidence repository.

[0020] In response to receiving the sealing identifier, the evidence repository performs integrity verification on the corresponding evidence package. If the verification passes, the evidence package is modified to a sealed state. The evidence package includes an event summary, the full text of the evidence, and an integrity verification field.

[0021] Furthermore, following any one or a combination of the aforementioned technical solutions, the evidence-gathering bypass module generates the integrity verification field in the following manner:

[0022] Calculate the effective payload hash corresponding to the full text of the evidence;

[0023] The payload hash is concatenated with the preceding hash, and the hash value of the concatenated payload hash and the preceding hash is calculated as the current hash, where the preceding hash is the current hash corresponding to the previous abnormal event.

[0024] The integrity verification field is determined to be {payload hash, previous hash, current hash}.

[0025] Furthermore, following any or a combination of the aforementioned technical solutions, the sealing identifier includes an event ID, a total number of blocks, and a payload hash, and the sealing identifier may optionally include a block hash;

[0026] The evidence repository verifies the integrity of the evidence package using the following methods:

[0027] Determine the evidence package and sealing identifier corresponding to the same event ID, and determine whether the number of evidence blocks in the evidence package is consistent with the total number of blocks in the sealing identifier;

[0028] The hash of each evidence block in the evidence package is recalculated, and it is determined whether the recalculated hash of each evidence block is consistent with the block hash in the block index; if the sealing identifier also includes a block hash, it can also be determined whether the recalculated hash of each evidence block is consistent with the block hash in the sealing identifier.

[0029] Recalculate the hash of all evidence blocks in the evidence package and compare it with the effective payload hash stored in the sealing identifier;

[0030] If all of the above are consistent, the integrity check passes.

[0031] Furthermore, following any one or a combination of the aforementioned technical solutions, the sealing identifier further includes a previous hash and a current hash;

[0032] The current hash is recalculated based on the preceding hash and the payload hash, and compared with the current hash in the sealed identifier. If they match, the integrity check passes.

[0033] Furthermore, following any one or a combination of the aforementioned technical solutions, each computing node on the inference link is electrically connected to the evidence bypass module. The inference task of the computing node is completed by the inference server. The evidence bypass module is independent of the inference server. Multiple evidence bypass modules and the evidence bus constitute the evidence bypass plane.

[0034] Furthermore, following any one or a combination of the aforementioned technical solutions, when no abnormal event is triggered, the evidence collection bypass module is configured to collect evidence prompts on the inference link at a first sampling frequency;

[0035] When an abnormal event is triggered, the evidence bypass module is configured to collect the full text of the evidence at a second sampling frequency, which is greater than the first sampling frequency.

[0036] Furthermore, following any one or a combination of the aforementioned technical solutions, the method further includes a pre-configured anchoring server connected to the evidence repository, configured to provide evidence materials for abnormal events to anchor roots, the evidence materials including anchor record signatures, and the integrity verification field including integrity verification signatures.

[0037] The anchoring server performs the anchoring verification process based on the following steps:

[0038] Signature verification: Verify the integrity check signature and the anchor record signature respectively;

[0039] Chaincheck: Verifies the match between the current hash and the effective payload hash;

[0040] Anchor verification: Read the proof path corresponding to the event ID, recalculate the root hash, and compare the root hash with the root hash in the anchor record. If they match, the verification passes; otherwise, it fails.

[0041] Furthermore, following any one or a combination of the aforementioned technical solutions, the method further includes a pre-configured playback arranger connected to the evidence storage compartment, which is configured to perform the following steps:

[0042] Pull the image and dependencies corresponding to the container image. When the runtime environment hash and configuration digest are consistent with the runtime environment hash and configuration digest corresponding to the evidence package, load the model corresponding to the model hash and the feature engineering corresponding to the feature hash.

[0043] Following the input reconstruction inference rules specified in the playback prompts, the input data blocks and key feature snapshots are restored to obtain the reproduced output and intermediate quantity summary;

[0044] The intermediate quantity summary and output of the reproduced data are compared with the intermediate quantity summary and output of the full text of the evidence. If they match, it is determined that the data can be reproduced and a playback report is output. The playback report includes the event ID, playback environment summary, checkpoint difference list, attribution label and playback conclusion.

[0045] Furthermore, following any one or a combination of the aforementioned technical solutions, it also includes a pre-configured causal index graph module and a strategy publisher;

[0046] The causal index graph module serves as a platform index service. Its inputs are the event summary and replay report, and its output is a fixed set of nodes / edges formed by the event, version, route, instance, and release batch corresponding to the event summary. The causal index graph module supports clustering, filtering, and association retrieval.

[0047] The policy publisher takes a playback report as input and outputs a disposal policy package as output.

[0048] Furthermore, following any or a combination of the aforementioned technical solutions, the causal index graph module structurally binds event IDs with model versions, route summaries, instances, and release batches through the causal index graph, supports conditional filtering and associated retrieval, and supports clustering of similar abnormal events;

[0049] The playback orchestrator outputs a playback report in a fixed format, and the strategy publisher archives and registers the handling actions and strategies in a versioned manner to form a closed-loop traceability chain of accident evidence, verification playback and handling release, so as to reuse historical handling experience.

[0050] Furthermore, following any one or a combination of the aforementioned technical solutions, the evidence-gathering bypass module determines whether an abnormal event is triggered based on evidence prompts during the reasoning process, including:

[0051] A first calculation window is preset. If the target quantile of the delay is greater than the threshold of the delay quantile in the historical window within the first calculation window, an abnormal event is determined to be triggered.

[0052] A second calculation window is preset. If the output value of the inference link exceeds the preset output range threshold within the second calculation window, an abnormal event is determined to be triggered.

[0053] Determine the confidence level of the reasoning result. If the confidence level is less than the confidence level threshold N times consecutively, where N is a natural number greater than 1, then an abnormal event is determined to have been triggered.

[0054] A third calculation window is preset. If the feature drift of the inference link exceeds the preset feature drift range within the third calculation window, an abnormal event is determined to be triggered.

[0055] A fourth calculation window is preset. If the error rate of the inference link exceeds the preset error rate threshold within the fourth calculation window, an abnormal event is determined to be triggered. Any two of the first, second, third, and fourth calculation windows are the same or different.

[0056] If a preset exception code is generated, including timeout, model loading failure, and missing dependency, then an exception event is determined to be triggered.

[0057] Furthermore, following any one or a combination of the aforementioned technical solutions, the evidence collection bypass module enters the event creation state after an abnormal event is triggered to generate an event header and an event summary;

[0058] After transmitting the event summary to the evidence repository, the evidence collection bypass module enters the event recording state to perform abnormal event recording, segmentation, and transmission.

[0059] After all evidence blocks have been transmitted to the evidence repository, the evidence bypass module enters an event sealing state to prevent the full text of the evidence from being tampered with.

[0060] Furthermore, following any one or a combination of the aforementioned technical solutions, the event digest includes an event header, a decision trajectory segment, and a computation specification segment; the evidence package includes an event header, a decision trajectory segment, a computation specification segment, an integrity verification field, and a playback prompt, wherein the integrity verification field is the hash value of the payload of the event digest, and the playback prompt includes playback steps and verification points.

[0061] According to another aspect of the present invention, a verifiable data processing apparatus for online reasoning is provided, which performs verifiable evidence recording, chain sealing and playback processing on data of abnormal events based on any one of the above technical solutions or a combination of multiple technical solutions.

[0062] According to another aspect of the present invention, a verifiable data processing system for online reasoning is provided, comprising the verifiable data processing apparatus for online reasoning as described in any one of the above technical solutions or a combination of multiple technical solutions.

[0063] The beneficial effects of the technical solution provided by this invention are as follows:

[0064] a. This invention connects each computing node on the inference link to the evidence collection bypass module electrically. The inference task of the computing node is completed by the inference server. The evidence collection bypass module is independent of the inference server. It collects evidence through the evidence bypass plane, which is fixed and independent. It sets up two layers of evidence carrying. The event summary is first confirmed and entered into the evidence bus, and the evidence block is then supplemented and entered into the evidence warehouse. Evidence is collected through an independent channel and is not mixed with the main inference link. This can avoid the problem of "business link being slowed down by evidence recording". It can also avoid problems such as incomplete evidence collection, large performance overhead, blurred accident boundaries and evidence data being overwritten.

[0065] b. After an abnormal event is triggered, this invention immediately packages, signs, and stores all evidence data belonging to this specific reasoning instance collected by the evidence collection bypass module within this time window into an unalterable evidence repository. This ensures that all accident-related data is defined according to a fixed starting point and fixed window pattern, with consistent evidence time periods. This facilitates subsequent automated comparison, statistical analysis, and attribution. After locking the boundaries and completing verification, the data is immediately sealed to prevent subsequent tampering, addition, or loss, thus ensuring the authenticity and integrity of the evidence. This achieves evidence fidelity and meets audit requirements.

[0066] c. In the absence of abnormal events, the evidence collection bypass module of this invention collects evidence prompts at a low or extremely low frequency, i.e., the first sampling frequency, to monitor the operation of the inference link. The storage overhead of this part is almost negligible. When an abnormal event is triggered, it immediately switches to the evidence collection mode of high fidelity and high sampling rate, i.e., the second sampling frequency. After the incident ends, it resumes low-power sampling, which not only ensures that the evidence is collected reliably and accurately when the problem occurs, but also reduces the overall overhead of the system.

[0067] d. The structured evidence package provided by this invention includes an event header, a decision trajectory segment, a calculation specification segment, the full text of the evidence, and an integrity verification field, which are encapsulated in sequence. The decision trajectory segment and the calculation specification segment are forced to be the components of the evidence package, which can ensure that the minimum set of evidence that can be located and replayed is solidified at the structural level. Furthermore, the sealing identifier and integrity verification field are generated through the evidence collection bypass module, and the evidence package is verified by the evidence storage side based on multiple hashes and the number of evidence blocks, which can ensure the reliability and integrity of the evidence.

[0068] e. This invention uses intra-event chained hashing to chain the full text of evidence over a long period of time according to the previous hash + the current hash, which can ensure that the sequential relationship of evidence within the same event cannot be rearranged / inserted. Furthermore, it generates root hashes for the sealed event set through periodic anchoring and saves the proof path of each event, so that any single abnormal event can provide verifiable proof materials "from the event to the anchor root".

[0069] f. This invention achieves causal indexing, playback, and closed-loop handling of abnormal events through the collaborative operation of a playback orchestrator, a causal index graph module, and a strategy publisher. When receiving an event summary, the causal index graph module writes key elements from the event summary into the causal index graph to form a structured binding. The playback orchestrator executes fixed steps for playback based on the calculated specification segment, full text of evidence, and playback prompts, generates a playback report, and writes it back to the evidence repository. When the playback conclusion meets fixed conditions, a handling strategy package is generated, versioned, archived, and registered in the graph, thus forming a reproducible and traceable closed loop for abnormal events. Attached Figure Description

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

[0071] Figure 1 A flowchart of a verifiable data processing method for online reasoning provided as an exemplary embodiment of the present invention;

[0072] Figure 2 A module block diagram of a first verifiable data processing apparatus provided as an exemplary embodiment of the present invention;

[0073] Figure 3 A block diagram of a second verifiable data processing apparatus provided as an exemplary embodiment of the present invention;

[0074] Figure 4 A block diagram of a third verifiable data processing apparatus provided for an exemplary embodiment of the present invention. Detailed Implementation

[0075] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. 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 should fall within the scope of protection of the present invention.

[0076] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, apparatus, product, or device that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or devices.

[0077] The composition (fixed deployment) of the inference system / computer system designed in this application and the definitions of the data objects involved are as follows.

[0078] Inference Service: This is the main link for business inference, used to receive inference requests, allocate routes, execute inference, and return execution results.

[0079] Evidence SIDecar: Deployed on the same node as the inference server, it is responsible for evidence collection, event windows, VRIT Record assembly, and chunked upload.

[0080] Evidence Bus: A channel for sequential transmission of event summaries, used for event "ownership and index entry" and the transmission of evidence packets.

[0081] Evidence Vault: A data storage unit for evidence, also known as an evidence repository, used to store large object evidence, playback reports, anchor records, strategy packages, etc.

[0082] Causal Index Graph: A structured index that shows the relationship between events and versions / routes / instances / release batches, etc.

[0083] Anchor Service: Used to periodically anchor the archived event set and generate root and proof paths.

[0084] Replay Orchestrator: Reconstructs and replays the environment according to evidence and computational specifications, and outputs a playback report.

[0085] Policy Publisher: Provides evidence, versioning, and registration of actions taken.

[0086] META: Event summary, first establish ownership through the evidence bus.

[0087] CTX INDEX: A list of indexes for evidence blocks.

[0088] FIN: Sealed identifier, declaring that the evidence block has been completed and used for integrity verification.

[0089] Anchor Record: Anchored record.

[0090] Proof Path: Event proof path.

[0091] Replay Report.

[0092] Remediation Package: Disposal strategy package.

[0093] In one embodiment of the present invention, a verifiable data processing method for online inference is provided, see [link to relevant documentation]. Figure 1 and Figure 2 This includes the following steps:

[0094] A bypass module for evidence collection, an evidence bus, and an evidence storage are pre-configured. The bypass module and the evidence storage are connected through the evidence bus, which is independent of the inference link.

[0095] The evidence-gathering bypass module determines whether an abnormal event has been triggered based on evidence prompts during the reasoning process. The evidence prompts include decision trajectory segments and calculation specification segments. If an abnormal event is triggered, the evidence-gathering bypass module performs the following operations:

[0096] Determine the trigger time of the abnormal event and a time window including the trigger time, and create an event header, the event header including event ID, inference request ID, trigger time and time window;

[0097] An event summary is generated and transmitted to the evidence repository via the evidence bus. The event summary includes the event header, the decision trajectory segment at the trigger time, and the calculation specification segment.

[0098] Collect the full text of the evidence corresponding to the time window, divide the full text of the evidence into multiple evidence blocks, configure a corresponding block index for the evidence block, and the block index includes the event ID, block ID and block hash corresponding to each evidence block;

[0099] First, each of the block indexes is transmitted to the evidence repository via the evidence bus. Then, each evidence block is transmitted to the evidence repository to obtain a structured evidence package, which can be used to verify the evidence record. After all the evidence blocks have been transmitted to the evidence repository, an integrity verification field is generated and an archiving identifier is sent to the evidence repository.

[0100] In response to receiving the sealing identifier, the evidence repository performs integrity verification on the corresponding evidence package. If the verification passes, the evidence package is modified to a sealed state. The evidence package includes an event summary, the full text of the evidence, and an integrity verification field.

[0101] In this embodiment, the evidence collection bypass module and the evidence bus constitute the evidence recording and transmission side, and the evidence warehouse is preferably set on the verification platform to constitute the platform verification and playback side. The evidence recording and transmission side, the platform verification and playback side, and the online reasoning service side where the reasoning link is located form three "non-interfering" service sides as shown in Table 1, which can realize the verifiable evidence recording, chain sealing and playback processing of abnormal event data without affecting the main reasoning process.

[0102] Table 1. Verifiable data processing device architecture for online inference

[0103]

[0104] In this embodiment, each computing node on the inference link is electrically connected to the evidence collection bypass module. The inference task of the computing node is completed by the inference server, and the evidence collection bypass module is independent of the inference server. This application, through the fixed and independent acquisition of evidence by the evidence bypass plane, ensures that evidence acquisition follows an independent channel and is not mixed with the main inference link. This avoids the problem of "the business link being slowed down by evidence recording," and also avoids problems such as incomplete evidence acquisition, high performance overhead, blurred accident boundaries, and evidence data overwriting.

[0105] Upon triggering an event, this application immediately packages, signs, and stores all evidence data belonging to that specific reasoning instance collected by the evidence collection bypass module within that time window into an immutable storage space, namely the evidence repository. This ensures that all incidents are defined according to a fixed starting point and fixed window pattern, with consistent evidence time periods, facilitating subsequent automated comparison, statistical analysis, and attribution. After locking the boundaries and completing verification, the evidence is immediately sealed to prevent subsequent tampering, addition, or loss, guaranteeing the authenticity and integrity of the evidence, ensuring evidence fidelity, and meeting audit requirements.

[0106] Preferably, when no abnormal event is triggered, the evidence collection bypass module is configured to collect evidence prompts on the inference link at a first sampling frequency; when an abnormal event is triggered / afterwards, the evidence collection bypass module is configured to collect the full text of the evidence at a second sampling frequency, where the second sampling frequency is greater than the first sampling frequency. In the absence of abnormal events, the evidence collection bypass module collects evidence prompts only at a low or very low frequency to monitor the operation of the inference link; the storage overhead of this part is almost negligible. When monitored indicators, such as error rate, latency P99, and output distribution offset, exceed the threshold, the system immediately switches to a high-fidelity, high-sampling-rate evidence collection mode. After the incident ends, low-power sampling is restored, ensuring that evidence is reliably and accurately collected when problems occur, while also reducing the overall system overhead.

[0107] In one embodiment of the present invention, see Figure 3 The verifiable data processing method for online reasoning is based on the collaborative work of multiple modules, including an "evidence bypass plane + evidence bus + evidence repository + causal index graph module + playback orchestrator + anchoring server + policy publisher," to achieve closed-loop processing of verifiable evidence recording, chained archiving, and playback disposal for online reasoning incidents. The deployment location, input / output, and responsibility boundaries of each module are fixed as follows.

[0108] The evidence bypass plane includes multiple evidence bypass modules. The input of each evidence bypass module (EvIDenceSIDecar) is the inference process summary stream and the corresponding window cache data. Its output is the event header, META, full text of evidence, and retransmission status. Its responsibilities are: isolated from the main inference link, responsible for the recording, transmission and encapsulation of evidence, and does not participate in inference business decisions.

[0109] The Evidence Bus is located in the platform message layer and is used to write data such as event headers, METAs, and evidence blocks sent by the evidence bypass module into the evidence repository.

[0110] The Evidence Vault serves as an object storage space and a dedicated evidence repository. It stores data such as evidence META, evidence packages, playback reports, and anchored proofs. Evidence packages are formed by event ID / event summary to create a set of evidence objects. Its responsibilities are to store evidence data and verify consistency by hashing evidence blocks.

[0111] The Causal Index Graph module serves as a platform indexing service, used to form a fixed set of nodes / edges based on the META (including version / route summary) events, versions, routes, instances, and release batches corresponding to abnormal events; it supports clustering, filtering, and association retrieval.

[0112] The Replay Orchestrator, as the platform execution plane, generates a Replay Report based on the calculation specification segment, replay prompts, full text of evidence, etc., to replay according to fixed steps, and generates a verification point summary and writes it back to the evidence repository.

[0113] The Anchor Service serves as the platform's auditing surface, generating Anchor Records and Merkle paths based on the current Curr Hash list of sealed events for anchoring at fixed intervals; and providing evidence of abnormal events leading to anchor roots.

[0114] The Policy Publisher serves as the platform's publishing surface. Its inputs are Replay Reports and attribution tags, and its output is a Remediation Package. Its function is to output a fixed-format policy package and archive it in a versioned manner.

[0115] To ensure that "rights are confirmed before evidence is provided, the chain of verification is established before playback, and the disposal is traceable", this application defines the following data objects and specifies their storage locations as shown in Table 2.

[0116] Table 2. Loading points and storage locations of evidence-related data

[0117]

[0118] In this embodiment, the process for handling abnormal events includes the following five steps.

[0119] Step 1: Create an exception event and generate an event header.

[0120] The evidence collection bypass module runs a fixed triggering rule, and after a trigger is successful, the event type and event code are determined.

[0121] The evidence collection bypass module locks the trigger time t0, preferably in milliseconds, and determines the time window [T] based on a preset window length. start T end ], and generate an event ID.

[0122] Through the above steps, the event header is obtained and set to the following fixed sequence: {Event ID, Inference Request ID, t0 (milliseconds), Event Type, Event Code, Window Start Time, Window End Time, Model Service, Project Identifier}. The Model Service includes the Inference Service ID, Inference Steps, and Route Summary, while the Project Identifier includes the Instance ID and Version ID.

[0123] The event header, as the lowest-level identifier / field of the abnormal event, is a set of identifiers and time fields, as shown in Table 3, used to describe the identity information of the abnormal event.

[0124] Table 3 defines the Event Header.

[0125]

[0126] Step 2: Generate an event summary (META), and the event enters the open evidence recording state (OPEN).

[0127] The forensic bypass module takes the newly formed event header, adds the Decision Trace and Compute Spec extracted from the evidence prompts, calculates the digest payload hash and an optional digest signature value as preliminary integrity correction fields, and packages them into a META. The fields and formats included in the Decision Trace are shown in Table 4, and the fields and formats included in the Compute Spec are shown in Table 5.

[0128] Table 4 Definition of Decision Trace

[0129]

[0130] The decision trajectory segment includes route summaries, model hashes, and feature hashes, while the computation specification segment includes runtime summaries. The event summary is immediately written to the evidence bus after generation to complete the confirmation of rights, and the event state enters the open recording state. The key to this step is speed and efficiency; it does not wait for the full text of the evidence.

[0131] In this embodiment, the event summary is set to the following fixed sequence: {event header, decision trajectory segment, calculation specification segment, initial integrity check field}.

[0132] Table 5. Definition of Compute Spec

[0133]

[0134] Process three, evidence collection, fragmentation, and transmission, is also the evidence recording and transmission process (OPEN).

[0135] The order of uploading evidence for abnormal events is as follows: META upload for ownership confirmation → block index upload → evidence block supplement upload → event completion confirmation. Specifically, after the event summary (META) is reported, the evidence collection bypass module collects a large volume of full-text evidence (input samples, feature snapshots, runtime parameters, etc.), as detailed in Table 6.

[0136] Table 6 Definition of Full-Text Evidence (Context)

[0137]

[0138] After obtaining the full text of the evidence, it is divided into evidence blocks of a fixed block size, a corresponding block index is generated, and each block is uploaded to the evidence repository, with missing blocks being retransmitted. The payload fields of the evidence block include the event ID, block index, block content bytes, and block hash. Preferably, the retransmission strategy for META is timeout retransmission, or a combination of timeout retransmission and a maximum number of retransmissions.

[0139] Step 4: Verified and Sealed Events: The evidence blocks are completed and verified by the fragment hash, thus completing the event sealing.

[0140] After the evidence block is completed, the evidence bypass module calculates the hash covering the entire content of the evidence block to obtain the payload hash. The calculation formula is as follows: Payload Hash(Event Header||DecisionTrace||Compute Spec||CTX INDEX||Context Total Hash), where "||" indicates concatenation of the preceding and following fields, and Context Total Hash is the full-text hash of the evidence.

[0141] The payload hash and the previous hash (Prev Hash) are then calculated to obtain the current hash (Curr Hash) to form a chain hash. The current hash calculation formula is: Curr Hash = SHA256(Prev Hash || Payload Hash). Optionally, the tenant ID digest can also be added when calculating the current hash (Curr Hash), and the calculation formula is: Curr Hash = SHA256(Payload Hash || Prev Hash || Tenant ID digest).

[0142] After obtaining the current hash, determine the integrity verification field, as shown in Table 7. The integrity verification field includes the payload hash, the previous hash, the current hash, and the integrity verification signature, i.e., Integrity Proof = {PayloadHash, Prev Hash, Curr Hash, Sig(Curr Hash)}.

[0143] Table 7 Integrity Proof Field

[0144]

[0145] The evidence bypass module generates a sealing identifier (FIN). The payload field of the sealing identifier FIN includes the event ID, the total number of blocks, and the current hash. Preferably, the sealing identifier also includes a payload hash; optionally, the sealing identifier includes a block hash. Then, the FIN is sent to the evidence repository, and the event status changes from OPEN to SEALED. At this point, all segments of the evidence packet are complete. This method ensures that all evidence is not tampered with, improving the integrity and credibility of the evidence.

[0146] The Anchor Service anchors evidence at fixed intervals, for example, every 10 minutes. Within each interval, the Anchor Service collects the current hash of events in the SEALED state, generates an anchor root according to fixed rules, and writes it to the anchor record. The specific process is as follows: Collection set: C = {(tenant ID digest || current hash)}, sorted lexicographically; Construct a Merkle tree: leaves are SHA256 (C), internal nodes are SHA256 (left || right), and the root is the anchor root (Root Hash).

[0147] Generate Anchor Record = {Period ID, Start Time, End Time, Number of Anchors, Anchor Root, Signature Value (Anchor Root)};

[0148] A Merkel path, or proof path, is generated for each event and bound to the event ID, then stored in the evidence repository.

[0149] When verifying the chain, the platform maintains the anchor hash (the latest confirmed current hash) by tenant ID and verifies that the preceding hash matches the signature. The verification process for anchor chain verification is as follows:

[0150] Signature verification: Verify the integrity check signature and the anchor record signature respectively;

[0151] Chaincheck: Verify that the current hash matches the hash of the payload.

[0152] Anchor verification: Read the proof path corresponding to the event ID and recalculate the root hash; compare the root hash with the root hash in the anchor record to see if they are consistent. If they are consistent, the verification passes; otherwise, the verification fails.

[0153] Once the anchor record is verifiable and the playback report has been generated, the event status changes from the sealed state to the verified state (VERIFIED).

[0154] Step 5: Policy Implementation (APPLIED). After the platform completes the anchoring verification, it performs replay verification. The replay orchestrator generates a replay report and writes it back to the evidence repository. The disposition policy package is then registered in the causal index graph module (RemediationPackage). The replay report includes at least the fields shown in Table 8.

[0155] Table 8. Replay Report Fields

[0156]

[0157] The playback orchestrator consistently executes the following steps, using the verification points of the decision trajectory segments as consistency criteria:

[0158] Pull the container image and its dependencies, and verify that the runtime hash and configuration digest are consistent.

[0159] Load the model corresponding to the model hash and the feature engineering corresponding to the feature hash.

[0160] Referring to Table 9, the input data block (Input Slice) and key feature snapshot (Feat Snapshot) are fully recovered based on the evidence according to the input reconstruction rules specified in the playback prompts.

[0161] Table 9 ReplayHint Definition

[0162]

[0163] Enable decision = 1, perform inference using a random seed (if provided), and obtain the output and intermediate summary. Compare the reproduced intermediate summary and output with the intermediate summary and output corresponding to the full text of the evidence: if they match, determine that it is reproducible; if they do not match, output the difference attribution (data / features / model / dependencies / runtime).

[0164] When the playback conclusion meets the preset fixed conditions, the playback orchestrator generates a remediation package as shown in Table 10, performs versioned archiving and release registration, and the event enters the APPLIED state.

[0165] Table 10 Fields of the Disposal Strategy Package

[0166]

[0167] Through processes one through five above, verifiable evidence of abnormal events is recorded, and an evidence package in the following serialized format is obtained: Event Header | DecisionTrace | Compute Spec | Context | IntegrityProof | ReplayHint. Based on the evidence package, the chained sealing and replay processing of abnormal events is realized.

[0168] In one embodiment of the present invention, the following lightweight online exception triggering rules are proposed to determine whether an exception event is triggered based on evidence prompts during the inference process, including: a preset first calculation window; if the target quantile of the delay is greater than the delay quantile threshold in the historical window within the first calculation window, an exception event is determined to be triggered; a preset second calculation window; if the output value of the inference link exceeds a preset output range threshold within the second calculation window, an exception event is determined to be triggered; the confidence level of the inference result is determined; if the confidence level is less than the confidence level threshold N times consecutively, where N is a natural number greater than 1, an exception event is determined to be triggered; a preset third calculation window; if the feature drift of the inference link exceeds a preset feature drift range within the third calculation window, an exception event is determined to be triggered; a preset fourth calculation window; if the error rate of the inference link exceeds a preset error rate threshold within the fourth calculation window, an exception event is determined to be triggered, wherein any two of the first, second, third, and fourth calculation windows are the same or different; and if a preset exception code appears, including timeout, model loading failure, and dependency missing, an exception event is determined to be triggered.

[0169] As shown in Table 11, any match in Table 11 indicates that an abnormal event has been triggered. Preferably, all statistical baseline windows are fixed to the most recent 6 hours, and the calculation period is fixed to 1 second, 2 seconds, or 5 seconds, etc.

[0170] Table 11 Rules for Triggering Abnormal Events

[0171]

[0172] Table 1 Explanation: Q99 (·) is the quantile threshold, reflecting the "adaptive binding of threshold and environmental baseline"; continuous hits are used to suppress jitter.

[0173] In one embodiment of the present invention, see Figure 4The evidence repository includes a first evidence repository and a second evidence repository. The evidence collection bypass module is electrically connected to the first evidence repository via a first evidence bus, which is configured to transmit the event digest, and the first evidence repository is configured to store the event digest. The evidence collection bypass module is also electrically connected to the second evidence repository via a second evidence bus, which is configured to transmit block indexes, evidence blocks, integrity check fields, and FINs, and the second evidence repository is configured to store these components. When the number of computing nodes is large, separating the transmission and storage of event digests and evidence can improve the overall evidence collection efficiency of the system. It should be noted that the first and second evidence repositories provided in this embodiment can be the same evidence repository. That is, only the event digests and evidence are transmitted separately, without partitioning the storage of the event digests and evidence. This allows multiple computing nodes to generate abnormal events, all of which are immediately written to the bus as META messages (appended sequentially), generating queryable event entries immediately. Large evidence blocks are then written to the evidence repository without blocking the confirmation of rights for abnormal events. This further forms a clear and reasonable method of evidence collection that immediately confirms rights through event summaries and then re-transmits the evidence content, with clear boundaries of responsibility.

[0174] The following is a more specific application example to illustrate the overall processing flow of recording, sealing and replaying evidence data corresponding to abnormal events in the reasoning system. See steps S1 to S12 below.

[0175] Step S1: The online reasoning service generates evidence prompts and transmits them to the evidence recording and transmission side.

[0176] After completing the execution of a reasoning request / task, the online inference service generates an evidence hint. The evidence hint consists of the following fixed fields:

[0177] (1) Request ID (Req ID), time (t), server ID (service ID Digest);

[0178] (2) Decision trajectory segment, see Table 4 above for details;

[0179] (3) Calculate the specification section, see Table 5 above for details;

[0180] (4) Other optional fields, such as trigger level: 0 = no anomaly; 1 = anomaly trigger; context ref, pointing to input sample / feature snapshot / key intermediate result, etc.

[0181] The online inference service writes the evidence hints to the evidence bypass module via local UDS or shared memory queue. The inference server only outputs the summary and citations, without assembling or uploading them.

[0182] Step S2: The evidence collection bypass module receives evidence prompts and creates / updates events (event state machine start point).

[0183] The input of the evidence collection bypass module is evidence prompts, and the output is the trigger creation event and evidence-related data.

[0184] The evidence collection bypass module maintains an event state machine, with the event key being the event ID: if the trigger indicator = 0, it is only used to update the local most recent evidence cache (which can be used for subsequent window rereading), and no event is created; if the trigger indicator = 1, it enters the event creation process (S3).

[0185] Step S3: Lock the event window and generate the event ID (fixed boundary).

[0186] The input to the evidence collection bypass module is the trigger time ts.

[0187] The process is as follows: Fix the starting point of the event: t0 = ts.

[0188] Fix the window as follows:

[0189] t begin =t0-T pre *1000;

[0190] t end =t0+T post *1000;

[0191] Among them, T pre T post This is a fixed configuration item for the evidence collection bypass module and is a preset value.

[0192] Event IDs can be generated using a fixed algorithm, such as the UUIDv4 algorithm, or according to preset numbering rules.

[0193] An event log structure is created within the evidence collection bypass module, represented as: Event Header = {Event ID, t} begin ,t0,t end ,state=OPEN,...}.

[0194] The event has entered the recording state.

[0195] Step S4: Generate META and write it into the evidence repository for initial rights confirmation.

[0196] Input: Summary field from the event header and evidence hints.

[0197] Processing: Construct a META, with fields including an event header, decision trajectory segment, calculation specification segment, preliminary integrity correction field, and META signature. If META signing is enabled, the preliminary integrity correction field is signed; otherwise, it is left empty.

[0198] Output: Write META to the evidence bus and receive an acknowledgment signal from the evidence bus.

[0199] Step S5: Inputting the graph index into the database (the META is written into the causal index graph module as soon as it arrives at the evidence warehouse).

[0200] Input: META.

[0201] Processing: The causal index graph module executes the index service to determine the META and writes the fixed associations:

[0202] Nodes: Event ID, Model Hash, Feature Hash, Route Summary, Runtime Status Summary, Instance ID, Publish ID.

[0203] Edges: Event ID to Model Hash, Event ID to Feature Hash, Event ID to Route Summary, Event ID to Runtime Summary, Event ID to Instance ID, Event ID to Publish ID.

[0204] Output: Successful map writing flag (internal).

[0205] Step S6: The evidence bypass module collects the full text of the evidence and forms a standard evidence structure (fixed content set).

[0206] Input: The full text of the evidence within the time window.

[0207] Processing: The evidence bypass module generates full text of evidence according to a fixed content set, which includes at least the following three categories: (1) input sample, including input summary and necessary fragments; (2) feature snapshot summary, including feature source, version, key vector summary; (3) key running state, including version / batch, temperature, key features, quantization switch, cache hit summary, etc.; and organizes the above into full text of evidence according to a fixed field order.

[0208] Output: Full text of the evidence (memory object).

[0209] Step S7: Divide the full text of the evidence into blocks according to the preset block division rules and generate the corresponding block index.

[0210] Input: Full text of the evidence.

[0211] Processing: Fixed block size (e.g., 1MB); sequentially split the full text of the evidence to obtain evidence blocks;

[0212] Calculate the hash of each evidence block;

[0213] Generate a block index, including event ID, block ID, etc. After generating the block index, each evidence block includes at least an event ID, a block ID, and corresponding evidence data.

[0214] Calculate the block hash of all evidence blocks.

[0215] Calculate the hash of the full text of all evidence blocks, i.e., the full text of the evidence.

[0216] Output: Block index and set of evidence blocks.

[0217] Step S8: Upload block index and evidence blocks (fixed order + missing block re-upload)

[0218] First, upload all block indexes to the evidence repository, then upload each evidence block to the evidence repository.

[0219] The evidence repository returns a missing block retransmission request / a list of missing blocks (if any).

[0220] The evidence collection bypass module retransmits evidence blocks according to the missing block retransmission request / missing block list until the missing blocks are empty.

[0221] Step S9: The evidence repository generates an integrity verification field and sends the sealing identifier FIN.

[0222] Input: META (local copy), block indexes, and the entire database.

[0223] Processing: Determine the integrity verification field. In this embodiment, the integrity verification field is determined according to the following algorithm:

[0224] Calculate the payload hash: Payload Hash = SHA256(Event Header||DecisionTrace||Compute Spec||CTX INDEX||context total hash), where Payload Hash represents the payload hash, context total hash represents the full-text hash of the evidence, and CTX INDEX represents the block index;

[0225] Determine the Prev Hash: Take the current hash of the last sealed event with the same server digest ID; if it does not exist, set an initial hash as the prev hash.

[0226] The current hash (Curr Hash) corresponding to the abnormal event is calculated using the following algorithm: Curr Hash = SHA256(Prev Hash || Payload Hash).

[0227] If signing is enabled, the current hash is signed to generate a sealed signature Sig = Sign(Curr Hash), where Sign is the preset signature algorithm.

[0228] The integrity verification field = {payload hash, previous hash, current hash, integrity verification signature}.

[0229] Construct the sealing identifier FIN, which includes FIN={event ID, total number of blocks, full-text hash of evidence, payload hash, previous hash, current hash, sealing signature}.

[0230] Write the integrity check field and FIN into the evidence bus.

[0231] Output: The event status is set to sealed. Based on the sealed identifier, the platform verification and playback side initiates integrity verification to confirm the reliability and integrity of the evidence package.

[0232] Step S10: Trigger the start verification procedure after FIN arrives at the evidence warehouse.

[0233] Perform the following fixed verification sequence:

[0234] Verify that the block index exists and matches the total number of blocks, or verify the seal identifier;

[0235] Recalculate the hash of each evidence block and compare it with the block hash in the block index;

[0236] Recalculate the hash of all evidence blocks and compare it with the full-text hash of the evidence in the sealing identifier;

[0237] Recalculate the payload hash and / or the current hash and compare it with the payload hash and / or the current hash in the FIN;

[0238] Verify the sealed signature (if enabled).

[0239] If all events pass, the event is marked as sealed and a sealing identifier is written into the causal index graph module. Abnormal events can then enter the anchoring and replay queue.

[0240] Step S11: Periodic anchoring of the anchor server.

[0241] The anchoring server periodically acquires a set of newly added sealed events in the evidence repository, including the event ID and the corresponding current hash.

[0242] The processing procedure is as follows: Leaves are formed based on the following calculation formula: leaf(i) = SHA256(Tenant digest||Curr Hash(i)), and each leaf is sorted, where i represents the i-th abnormal event, Tenant digest represents the tenant digest, and Curr Hash(i) represents the i-th abnormal event;

[0243] Construct a Merkle tree to obtain the root hash;

[0244] Write to the anchor record, Anchor Record = {epoch ID, t begin , t end The code snippet lists the anchor records and stores them in the evidence repository. The epoch ID is the anchor period ID. begin , t end The anchor record is defined by its start and end times, count is the number of exception events, and Sig (Root Hash) is the anchor signature.

[0245] Generate a proof path for each event and write it to the proof repository: vrit / {eventID} / anchor / proof.json.

[0246] Output: The event has anchored evidence.

[0247] Step S12: Closed loop of playback arrangement, report generation and processing

[0248] The input data consists of: META + full text of evidence + Integrity Proof field + Proof Path.

[0249] Processing procedure: The replay orchestrator reads the Compute Spec segment, reconstructs the replay environment digest, loads the full text of evidence according to fixed steps, and performs inference replay;

[0250] Generate a replay report, which includes the following fields: event ID, replay environment digest, checkpoint diffs, root cause tag, replay conclusion, and timestamp ts. See Table 8 for details.

[0251] Write the playback report back to the evidence repository.

[0252] The Policy Publisher generates a Remediation Package based on fixed rules. The Remediation Package includes the following fields: Package ID, Event ID, Target Scope, Action, Params Digest, Package Hash, Remediation Signature, and Publish ID. For detailed meanings and types of each field, please refer to Table 10.

[0253] The disposal strategy package is written back to the evidence repository and the event ID, strategy package hash, and publication ID are registered in the causal index graph module.

[0254] Output: Event completion marker (platform verification and playback side).

[0255] The verifiable data processing method for online reasoning proposed in this application has at least the following advantages compared to existing methods for handling incidents during online reasoning.

[0256] (1) It can reduce the additional load during online inference and online incidents, and avoid the back-end delay of evidence recording. Since the evidence collection adopts a bypass evidence collection module and an independent evidence channel, and the event boundary is sealed with a fixed back window, the main inference link does not need to synchronously write large objects or block and wait for evidence to be written to disk. The evidence collection process does not affect the main inference business, and the main inference business will not cover the important data that needs to be collected. Moreover, under the high pressure of an incident, the impact of evidence recording on online performance can be limited to "event summary level overhead", which can significantly reduce the risk of secondary failures caused by recording evidence.

[0257] (2) It can realize "first confirming rights, then supplementing evidence", so that searchable event entries can be formed as soon as possible after the incident. By writing event summaries into the evidence bus to establish an event index, and then writing the full text of the evidence into the evidence warehouse in blocks, the incident confirmation and retrieval entry can be completed before the evidence is fully supplemented. Incident location can be changed from "waiting for files / logs to be complete" to "seeing the event first, then supplementing evidence", shortening the start time of the first round of location.

[0258] (3) Standardized evidence structure enables accident records to be aligned, compared, and batch statistically analyzed. The structured evidence package proposed in this application includes the following fixed field set: event header, decision trajectory segment, calculation specification segment, full text of evidence, and integrity verification field, making the evidence form consistent across different accidents. By fixing the boundary rules of abnormal events through time windows including the trigger time, the length of each event window is ensured to be consistent, thereby supporting cross-event alignment comparison, threshold verification, cluster statistics, and playback consistency assessment.

[0259] (4) The context can still be supplemented under weak network, traffic limiting, or intermittent link conditions, and the supplementation process is verifiable. This application implements missing block supplementation through block index and evidence blocks, and ensures that the event is sealed only when the block is supplemented and verified through the sealing identifier FIN. This improves the final completeness rate of the full text of the evidence and reduces "evidence missing events" caused by network instability.

[0260] (5) The evidence is verifiable and credible: it can be proven that the evidence has not been tampered with, has not been inserted, and is traceable to the platform anchor root. This application uses an internal chained hash to give the event evidence objects an order constraint, preventing post-event rearrangement / insertion; the platform periodic anchoring allows a single event to independently generate anchoring proof materials. This upgrades the evidence from the "credible assumption of internal logs" to "computable and verifiable credible evidence", meeting the authenticity requirements of auditing, compliance, or dispute arbitration scenarios.

[0261] (6) It can significantly improve the efficiency of cross-layer localization and root cause analysis, and form a traceable closed loop of "replay verification - disposal release". This application uses a causal index graph to structurally bind event IDs with model versions, route summaries, instances, release batches, etc., which can quickly filter and retrieve related information by conditions, and supports clustering of similar abnormal events. Furthermore, a fixed-format replay report is output through a replay orchestrator, and disposal actions are archived and associated with versioned disposal strategies, thereby forming a closed-loop traceability chain of "accident evidence - verification replay - disposal release", which facilitates the reuse of historical disposal experience and reduces the cost of handling repeated accidents.

[0262] In one embodiment of the present invention, an incident debriefing method for online reasoning is provided. The incident debriefing method is based on the verifiable data processing method for online reasoning described in the above embodiment, which performs verifiable evidence recording, chain sealing and playback processing on the data corresponding to the abnormal event.

[0263] In one embodiment of the present invention, a verifiable data processing device for online reasoning is provided. The data processing device is provided with an evidence bypass plane, evidence bus, evidence warehouse, causal index graph module, playback orchestrator, anchoring server and policy publisher as described in the above embodiments. The verifiable data processing device performs verifiable evidence recording, chain sealing and playback processing on the data corresponding to abnormal events based on the verifiable data processing method for online reasoning described in the above embodiments.

[0264] In one embodiment of the present invention, a verifiable data processing system for online reasoning is provided, including the verifiable data processing apparatus for online reasoning as described in the above embodiment.

[0265] It should be noted that the embodiments of the above-described incident debriefing method, verifiable data processing device, and verifiable data processing system for online reasoning are based on the same inventive concept as the embodiments of the verifiable data processing method for online reasoning. All contents of the embodiments of the verifiable data processing method for online reasoning are incorporated into the embodiments of the incident debriefing method, verifiable data processing device, and verifiable data processing system for online reasoning by reference.

[0266] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0267] The above description is only a specific embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A verifiable data processing method for online inference, characterized in that, Includes the following steps: A bypass module for evidence collection, an evidence bus, and an evidence storage are pre-configured. The bypass module and the evidence storage are connected through the evidence bus, which is independent of the inference link. The evidence-gathering bypass module determines whether an abnormal event has been triggered based on evidence prompts during the reasoning process. The evidence prompts include decision trajectory segments and calculation specification segments. If an abnormal event is triggered, the evidence-gathering bypass module performs the following operations: Determine the trigger time of the abnormal event and a time window including the trigger time, and create an event header, the event header including event ID, inference request ID, trigger time and time window; An event summary is generated and transmitted to the evidence repository via the evidence bus. The event summary includes the event header, the decision trajectory segment at the trigger time, and the calculation specification segment. Collect the full text of the evidence corresponding to the time window, divide the full text of the evidence into multiple evidence blocks, configure a corresponding block index for the evidence block, and the block index includes the event ID, block ID and block hash corresponding to each evidence block; First, each of the block indexes is transmitted to the evidence repository via the evidence bus. Then, each evidence block is transmitted to the evidence repository to obtain a structured evidence package. After all evidence blocks have been transmitted to the evidence repository, an integrity verification field is generated and an archiving identifier is sent to the evidence repository. In response to receiving the sealing identifier, the evidence repository performs integrity verification on the corresponding evidence package. If the verification passes, the evidence package is modified to a sealed state. The evidence package includes an event summary, the full text of the evidence, and an integrity verification field.

2. The verifiable data processing method for online inference according to claim 1, characterized in that, The evidence collection bypass module generates the integrity verification field in the following manner: Calculate the effective payload hash corresponding to the full text of the evidence; The payload hash is concatenated with the preceding hash, and the hash value of the concatenated payload hash and the preceding hash is calculated as the current hash, where the preceding hash is the current hash corresponding to the previous abnormal event. The integrity verification fields are determined to include {payload hash, previous hash, current hash}.

3. The verifiable data processing method for online inference according to claim 2, characterized in that, The archive identifier includes the event ID, the total number of blocks, and the payload hash; The evidence repository verifies the integrity of the evidence package using the following methods: Determine the evidence package and sealing identifier corresponding to the same event ID, and determine whether the number of evidence blocks in the evidence package is consistent with the total number of blocks in the sealing identifier; Recalculate the hash of each evidence block in the evidence package, and determine whether the recalculated hash of each evidence block is consistent with the block hash in the block index; Recalculate the hash of all evidence blocks in the evidence package and compare it with the effective payload hash stored in the sealing identifier; If all of the above are consistent, the integrity check passes.

4. The verifiable data processing method for online inference according to claim 3, characterized in that, The sealing identifier also includes the previous hash and the current hash; The current hash is recalculated based on the preceding hash and the payload hash, and compared with the current hash in the sealed identifier. If they match, the integrity check passes.

5. The verifiable data processing method for online inference according to claim 1, characterized in that, Each computing node on the inference chain is electrically connected to the evidence collection bypass module. The inference task of the computing node is completed by the inference server, and the evidence collection bypass module is independent of the inference server.

6. The verifiable data processing method for online inference according to claim 1, characterized in that, When no abnormal event is triggered, the evidence collection bypass module is configured to collect evidence prompts on the inference link at a first sampling frequency; When an abnormal event is triggered, the evidence bypass module is configured to collect the full text of the evidence at a second sampling frequency, which is greater than the first sampling frequency.

7. The verifiable data processing method for online inference according to claim 1, characterized in that, The integrity verification field includes an integrity verification signature; It also includes a pre-configured anchoring server connected to the evidence repository, which is configured to provide evidence of anomalies to anchoring roots, the evidence including anchoring record signatures; The anchoring server performs the anchoring verification process based on the following steps: Signature verification: Verify the integrity check signature and the anchor record signature respectively; Chaincheck: Verifies the match between the current hash and the effective payload hash; Anchor verification: Read the proof path corresponding to the event ID, recalculate the root hash, and compare the root hash with the root hash in the anchor record. If they match, the verification passes; otherwise, it fails.

8. The verifiable data processing method for online inference according to claim 1, characterized in that, It also includes a pre-configured playback orchestrator connected to the evidence repository, which is configured to perform the following steps: Pull the image and dependencies corresponding to the container image. When the runtime environment hash and configuration digest are consistent with the runtime environment hash and configuration digest corresponding to the evidence package, load the model corresponding to the model hash and the feature engineering corresponding to the feature hash. According to the input reconstruction reasoning rules specified in the playback prompts, restore the input data blocks and key feature snapshots in the full text of the evidence to obtain the reproduced output and intermediate quantity summary; The intermediate quantity summary and output of the reproduced data are compared with the intermediate quantity summary and output of the full text of the evidence. If they match, it is determined that the data can be reproduced and a playback report is output. The playback report includes the event ID, playback environment summary, checkpoint difference list, attribution label and playback conclusion.

9. The verifiable data processing method for online inference according to claim 8, characterized in that, It also includes a pre-configured causal index graph module and a policy publisher; The causal index graph module serves as a platform index service. Its inputs are the event summary and replay report, and its output is a fixed set of nodes / edges formed by the event ID, model version, route, instance, and release batch graph corresponding to the event summary. The policy publisher takes a playback report as input and outputs a disposal policy package as output.

10. The verifiable data processing method for online inference according to claim 9, characterized in that, The causal index graph module structurally binds event IDs with model versions, route summaries, instances, and release batches through the causal index graph, supports conditional filtering and related retrieval, and supports clustering of similar abnormal events; The playback orchestrator outputs a playback report in a fixed format, and the strategy publisher archives and registers the handling actions and strategies in a versioned manner to form a closed-loop traceability chain of accident evidence, verification playback and handling release, so as to reuse historical handling experience.

11. The verifiable data processing method for online reasoning according to claim 1, characterized in that, The evidence-gathering bypass module determines whether an abnormal event has been triggered based on evidence prompts during the reasoning process, including: A first calculation window is preset. If the target quantile of the delay is greater than the threshold of the delay quantile in the historical window within the first calculation window, an abnormal event is determined to be triggered. A second calculation window is preset. If the output value of the inference link exceeds the preset output range threshold within the second calculation window, an abnormal event is determined to be triggered. Determine the confidence level of the reasoning result. If the confidence level is less than the confidence level threshold N times consecutively, where N is a natural number greater than 1, then an abnormal event is determined to have been triggered. A third calculation window is preset. If the feature drift of the inference link exceeds the preset feature drift range within the third calculation window, an abnormal event is determined to be triggered. A fourth calculation window is preset. If the error rate of the inference link exceeds the preset error rate threshold within the fourth calculation window, an abnormal event is determined to be triggered. Any two of the first, second, third, and fourth calculation windows are the same or different. If a preset exception code is generated, including timeout, model loading failure, and missing dependency, then an exception event is determined to be triggered.

12. The verifiable data processing method for online reasoning according to claim 1, characterized in that, The evidence collection bypass module enters the event creation state after an abnormal event is triggered to generate an event header and an event summary. After transmitting the event summary to the evidence repository, the evidence collection bypass module enters the event recording state to perform abnormal event recording, segmentation, and transmission. After all evidence blocks have been transmitted to the evidence repository, the evidence bypass module enters an event sealing state to prevent the full text of the evidence from being tampered with.

13. The verifiable data processing method for online reasoning according to claim 1, characterized in that, The evidence package includes an event header, a decision trajectory segment, a calculation specification segment, an integrity verification field, and a playback prompt. The integrity verification field is the hash value of the payload of the event summary, and the playback prompt includes playback steps and verification points.

14. A verifiable data processing device oriented to online inference, characterized by, Based on the verifiable data processing method for online reasoning as described in claim 1, verifiable evidence recording, chain-like sealing, and playback processing are performed on the data of abnormal events.

15. A verifiable data processing system oriented towards online inference, characterized in that, Includes the verifiable data processing apparatus for online reasoning as described in claim 14.

Images