Task result multiplexing method and corresponding computer device and program product

Abstract

The application discloses a task result multiplexing method and corresponding computer equipment and program product, and belongs to the field of electric digital data processing. In view of the obvious deficiency of the prior art in the aspects of long-term / short-term memory and external calling result fusion, cross-task semantic multiplexing, link-level migration and dynamic updating, the application inserts a collection / standardization / vectorization step between the input and output of each external retrieval knowledge base, function or tool calling, and writes the result in the form of a link unit into the memory. When the intelligent agent receives a user task, the existence of a related link unit in the memory is checked by adopting a mode of first hash accurate matching and then vector semantic matching, if the related link unit exists, the existing result is reused, if the related link unit does not exist, new retrieval / calling is performed, and the result and the calling parameter are stored into the system memory in the form of a link unit, thereby forming a traceable and reusable knowledge-function-tool link, and the multiplexing efficiency and correctness of the task result are improved.

Description

Technical Field

[0001] This application relates to the field of electronic digital data processing, and in particular to a method for reusing task results in the field of artificial intelligence and large model applications. Background Technology

[0002] In existing large-scale model applications or intelligent agent systems, external knowledge bases, function libraries, or tool invocations are typically relied upon to enhance the model's reasoning and execution capabilities. However, existing technologies have significant shortcomings in areas such as the fusion of system long / short-term memory and external invocation results, cross-task semantic reuse, link-level migration, and dynamic updates. Specifically,

[0003] 1) Independent storage and retrieval, lack of integration: Knowledge base retrieval results, function execution results, and tool call parameters are often stored separately and cannot be organically combined with the system's memory, making it difficult to maintain consistency for the same task in different contexts and requiring repeated queries or calculations;

[0004] 2) Limitations of traditional caching mechanisms: Some systems avoid repeated queries through caching mechanisms, but they only support hash matching of input conditions and cannot handle tasks with different semantics but the same intent, thus failing to meet the reuse requirements of diverse expressions in natural language tasks.

[0005] 3) Lack of link-level reuse capability: Existing solutions can only cache the final result and cannot reuse intermediate link information (such as call path, parameter configuration, etc.). When task variations occur, the system still needs to rebuild the complete call flow, which is inefficient.

[0006] 4) Insufficient update mechanism: Traditional caching does not take into account the real-time differences of external data, which can easily lead to expired or inconsistent results, and lacks dynamic update and version management mechanisms.

[0007] Therefore, there is a need to provide a task result reuse scheme that at least partially overcomes the above-mentioned defects. Summary of the Invention

[0008] This invention provides a method for reusing task results, as well as corresponding computer equipment and program products, which systematically solves the problem of low efficiency in task result reuse in the prior art and ensures the correctness of task result reuse.

[0009] In a first aspect of the present invention, a method for reusing task results is provided, the method comprising:

[0010] The input information of the current task is normalized according to the normalization rules to obtain its normalized representation, and the hash value of the normalized representation is calculated.

[0011] The hash value is matched with the key-value index in the computer system memory. The key-value index stores the direct mapping from the hash value of the canonical representation of the task input information corresponding to each link unit to the corresponding link unit. Each link unit is a structured storage model and includes the link unit ID, the hash value of the canonical representation of the corresponding task input information, the semantic vector of the corresponding task input information, and the corresponding task result. The task is knowledge base retrieval, function execution, or tool call.

[0012] If the first match does not find a link unit, the semantic vector of the current task input information is calculated and matched with the vector library stored in the computer system's memory. The vector library stores the semantic vector of the corresponding task input information of each link unit.

[0013] If the second match still fails to find a link unit, a new knowledge base retrieval, function execution, or tool call is triggered based on the current task input information. The result, along with the corresponding hash value and semantic vector, is assembled into a link unit according to the link unit structured storage model. The hash value, semantic vector, result source, and result validity period in the link unit are written into the key-value index, vector library, and graph database in the computer system's memory, respectively, for matching during subsequent reuse.

[0014] If the first or second match hits a link unit, the task corresponding to the current task input information will no longer be executed, and the task result in the hit link unit will be reused.

[0015] In a second aspect of the invention, a computer device is provided, including a processor, a memory, and a computer program stored in the memory, wherein the processor executes the computer program to implement the steps of the method described in the first aspect.

[0016] In a third aspect of the invention, a computer program product is provided, comprising a computer program / instructions, characterized in that, when executed by a processor, the computer program / instructions implement the steps of the method described in the first aspect.

[0017] This invention provides a method for enabling intelligent agents to organically combine memory with knowledge base retrieval results, function execution results, and tool call results during dialogue, reasoning, and task execution, thereby improving the coherence of information processing and the reusability of task execution. Compared with existing technologies, it has the following advantages:

[0018] - Not a regular cache: Link units store a composite structure of links and contexts (including call chains, sources, versions, and vectors), not just the hash values ​​of the inputs.

[0019] - Two-layer matching (precise + semantic): It balances low-latency precise reuse with high-coverage semantic reuse, solving the problem that a single hash cannot cover different representations of the same graph.

[0020] - Link-level reuse and partial reuse: Reuse intermediate links (such as knowledge retrieval results) and re-execute non-reusable links with minimal cost to improve efficiency and ensure correctness.

[0021] - Verification and update mechanism: Validity checks before reuse, re-verification triggered by external changes, and versioning ensure reuse security and avoid errors caused by "outdated results".

[0022] - Traceability and auditability: Comprehensive traceability information and source of results support traceability and legal / compliance requirements.

[0023] Other features and advantages of the present invention will become clearer after reading the detailed description of the embodiments of the present invention in conjunction with the accompanying drawings. Attached Figure Description

[0024] Figure 1 This is a flowchart of an embodiment of the method according to the present invention.

[0025] For clarity, these figures are schematic and simplified, showing only the details necessary for understanding the invention, while omitting other details. Detailed Implementation

[0026] The embodiments and examples of the present invention will now be described in detail with reference to the accompanying drawings.

[0027] The scope of the invention will become apparent from the detailed description given below. However, it should be understood that while the detailed description and specific examples illustrate preferred embodiments of the invention, they are given for illustrative purposes only.

[0028] To improve the efficiency and accuracy of task result reuse, the system's long / short-term memory needs to be directly integrated with knowledge base retrieval results, function execution results, and tool call parameters to form a unified, reusable link unit. Cross-task link reuse needs to be supported, ensuring efficient reuse of repetitive tasks while also supporting the reuse of intents expressed differently. The validity and consistency of results must be guaranteed during link reuse, including validity period management and dynamic updates. An evolution from result-level reuse to link-level reuse is needed to improve the overall system efficiency and intelligence.

[0029] Figure 1 An embodiment of a task result reuse method according to the present invention is shown. This embodiment is based on the link unit proposed in this invention. Each link unit is a structured storage model and includes, for example, the following fields:

[0030] LinkID, Link Unit ID

[0031] TaskID, Task Identifier

[0032] InputText is the task of users inputting raw information to express content or make calls.

[0033] InputSignature, a normalized / standardized representation of the original task input information.

[0034] CanonicalHash, a hash value representing the normalized / standardized representation of the original input information, is used for precise matching.

[0035] Embedding, a vector data containing the original input information, is used for vector retrieval.

[0036] EmbeddingMeta, vector-related metadata (used for index filtering)

[0037] KnowledgeResult, the result of a knowledge base search.

[0038] FunctionResult, the result of tool / function execution.

[0039] ExecutionTrace allows for tracing intermediate steps.

[0040] Provenance, the source of task results (used for tracing or auditing results): records the complete source chain, such as the specific dataset ID, API endpoint, request parameter summary, execution node information, etc.

[0041] ValidUntil, the validity period of the task result.

[0042] Confidence, Reusability

[0043] Version

[0044] needs_revalidation, the revalidation flag.

[0045] The link unit not only stores the final value of the task execution, but also the call chain, source and version, semantic vector and precise hash, ensuring that it can perform both precise caching and semantic reuse and traceability.

[0046] In step S1, the input information of the current task is normalized based on the normalization rules to obtain its normalized representation, and the hash value of the normalized representation is calculated.

[0047] The purpose of this step is to standardize synonymous but differently formatted inputs / calls (including different function signatures, parameter orders, and textual differences) as much as possible to obtain the same result, reduce hashing errors, support operations such as caching, indexing, comparison, and knowledge fusion, and improve the exact matching hit rate. Normalized representation is a unique, comparable, and indexable structured representation of input content (such as function calls, query requests, knowledge units, semantic fragments, etc.) after a series of rule-based, structuring, denoising, and standardization processes.

[0048] Tasks can include knowledge base retrieval, function execution, or tool invocation. Normalization rules are configurable and versionable.

[0049] Normalization processes include one or more of the following:

[0050] 1) Parameter sorting: Sort the parameters in the current task input information so that inputs with different parameter orders for the same function have the same representation, such as {a:1,b:2} and {b:2,a:1}.

[0051] 2) Alias ​​Mapping: Unify the aliases of functions, fields and / or units in the current task input information to the standard names. For example, map "getMA" and "getMovingAverage" to the unified internal signature, and map "fetchUser" to "get_user_info", etc.

[0052] 3) Unit standardization: Standardize the physical quantities or quantities in the current task input information to standard units, for example, "3 km" to "3000 m".

[0053] 4) Default value expansion: Explicitly completes the default parameters omitted in the current task input information to make the semantics complete.

[0054] 5) Context trimming: Perform context trimming on the current task input information according to the trimming strategy to remove context noise fields that are irrelevant to the task, such as log time and temporary token.

[0055] Context-based pruning strategies include semantic relevance-driven pruning, low-variability field pruning, time / state-sensitive field pruning, and context window constraints.

[0056] Semantic relevance-driven pruning: Calculate the semantic relevance between each context field in the current task input information and the task body, and retain only the highly relevant parts.

[0057] The current task can be "knowledge base retrieval, function execution, or tool call." After normalization, a structured representation, InputSignature, will be obtained (such as a unified function signature, standardized query text, etc.). If there is an explicit function / tool ​​call: Task body = Normalized function signature + key parameters (parameter-level fields). If it is a pure natural language query: Task = Normalized Query text (removing mood-level fields, retaining task-level + parameter-level fields). For complex tasks involving multiple external calls, the task body is determined at the "link unit" granularity. That is, each link unit corresponds to one external task, and within that link unit, the task body is the corresponding specific retrieval / call.

[0058] Implementation method:

[0059] Vectorize the task body and context field separately.

[0060] Calculate the semantic similarity between vectors using cosine_similarity(context, task).

[0061] Set a threshold θ (e.g., 0.65); context fields below the threshold are discarded.

[0062] Example:

[0063] User context: {Stock code: "AAPL", Last query time: "Yesterday", Window size: 30}

[0064] Current task: "Calculate the 30-day moving average".

[0065] By calculating semantic similarity, it can be determined that "last query time" is irrelevant to the task semantics (the result of cosine_similarity ≈ 0.2), and therefore it can be removed.

[0066] Low-variance field pruning: Statistically analyze the frequency of a field in similar tasks and its impact on the difference in results, and prune fields in the current task's input information that have low variation among similar tasks.

[0067] Implementation method:

[0068] Extract each field from the N most recent similar tasks (e.g., vector embedding similarity in link units > 0.8).

[0069] Calculate the variance Var_i of the field values ​​(this can be done using the numpy.var function).

[0070] If Var_i < threshold (which is almost constant), it is considered noise or default context and is pruned.

[0071] Example:

[0072] Filtering task-irrelevant content based on user language style differences (such as "please help me", "excuse me", "thank you", etc.).

[0073] Time / Status Sensitive Field Pruning: For short-term dynamic fields such as timestamps, session_ids, and runtime environment information in the current task input information, uniformly set them to empty or standardize them; the purpose is to eliminate time noise and prevent different hashes each time.

[0074] Implementation method:

[0075] If the field type is {timestamp, request ID, session number, browser parameters}, then delete it or set it to "". <normalized>".

[0076] If a field is a date-type parameter but its semantics affect the calculation (e.g., "past 30 days"), then the logical expression form is retained, and the specific date is not retained.

[0077] Example:

[0078] "query_time": "2025-10-21T16:23:45Z" → "query_time": " <normalized>"

[0079] "period": "Past 30 days" → Keep "period": "30d"

[0080] Context window constraint: Limits the size of the context window participating in normalization processing, avoids link pollution, controls the length of the canonical representation, and improves hash hit rate and performance.

[0081] Implementation method:

[0082] If the context length is greater than N (e.g., 2048 tokens), after sorting by semantic similarity, only the top K contexts most relevant to the task semantics are retained, and the last contexts are pruned.

[0083] 6) Deterministic serialization: The content of the current task input information after the above processing is serialized according to a fixed field order to obtain a standardized representation of the current task input information, so as to ensure comparability and hash stability.

[0084] It should be noted that normalization should not be overdone to avoid losing semantic differences. Over-normalization can be avoided through one or more of the following methods.

[0085] 1) Semantic difference detection: After normalization, it detects whether key semantic information is lost. This mechanism enables normalization to have "self-correction" capability.

[0086] Implementation method:

[0087] Calculate the semantic vector difference between the original input and the canonical representation.

[0088] If the difference exceeds the threshold θ (e.g., 0.15), it indicates that the normalization has been over-normalized, and the normalization rules should be rolled back or adjusted.

[0089] You can also mark certain fields as "semantic sensitive fields" so that the original values ​​are retained or weakly normalized during subsequent normalization.

[0090] Example:

[0091] Input: "Please calculate last week's sales figures"

[0092] Standardization: "Calculate sales revenue"

[0093] Δ = 0.37 > 0.15, so normalization should be rolled back, while retaining the time limit information.

[0094] When normalization is over-standardized, a rollback can be implemented, for example, as follows:

[0095] 1. Step-by-step replay of rules to locate the "problematic step / field".

[0096] Normalization is typically sequential (sorting → alias mapping → unit standardization → context pruning, etc.). Each step records which fields were modified / deleted and what actions were taken (e.g., deleting field X, changing "last week" to "last_week"), etc. For step i: calculate Δ_i = sim(original, norm_after_step_i). Find the point where the increment of Δ significantly increases (exceeding a local threshold) from a certain step, and mark that step as a "suspicious rule".

[0097] 2. Field-level rollback: Prioritize restoring fields with the greatest semantic differences.

[0098] Perform a "pseudo-recovery" on each of the "deleted / strongly normalized" fields {f1, f2, …} and observe the change in Δ. If "after recovering fi, the overall semantic difference decreases significantly" (Δ becomes significantly smaller), it indicates that fi carries key semantics and should be recovered. Only recover those fields that significantly contribute to Δ, and keep the remaining fields pruned.

[0099] This step can be combined with "semantic sensitive fields": sensitive fields can be directly restored or reverted to weak normalization, while non-sensitive fields can be tested one by one as described above.

[0100] 3. Combine with the "semantic sensitive field" whitelist

[0101] For fields that are marked as sensitive in business terms, such as time range, amount, and object entity, prioritize restoring the original value / weak normalization, and do not easily discard them even if their contribution to local Δ is not particularly significant.

[0102] 4. Regenerate the canonical representation

[0103] The normalization process will be redone based on the adjusted rules and recovery results (while continuing to support versioning / rollback).

[0104] In short: it's not about "restoring everything" or "restoring nothing," but rather about selecting the information that truly needs to be retained through a combination of vector differences, rule-based step records, and semantically sensitive fields.

[0105] 2) Hierarchical normalization strategy: Different normalization strategies are used for inputs of different fields / levels, which can prevent the task intent from being mistakenly eliminated, while improving the consistency of standardization.

[0106] hierarchy Example fields Normalization intensity illustrate mission level Task intent, domain keywords Weak normalization Preserve the differences; for example, "generate report" ≠ "generate summary". Parameter level Numerical value, time, unit Strong standardization Unit conversion, date standardization tone level Rhetoric, politeness, stop words Complete removal Does not affect semantics

[0107] Implementation method:

[0108] Define a hierarchical system for standardization rules (task-level / parameter-level / tone-level).

[0109] The normalization intensity is dynamically determined based on the task type template during the normalization process.

[0110] A task type template is a configuration / metadata for a specific task type (task_type), which specifies: a) what "fields" this type of task will have; b) which level each field belongs to (task level / parameter level / tone level); c) which normalization rules are applied to each level and their strength.

[0111] 3) Configurable and versionable rules: Avoid rigid fixed rules and enable the system to adapt and update according to task type, corpus changes or user strategies.

[0112] Implementation method:

[0113] Rule configuration: All standardized rules are stored in JSON / YAML format (which can be executed using rule engines such as Drools), as shown in the example below:

[0114] - rule_id: time_normalization

[0115] scope: ["date", "period"]

[0116] strength: "strong"

[0117] version: 1.2

[0118] sample_patterns:

[0119] - "last week" → "last_week"

[0120] - "Past 30 days" → "30d"

[0121] Rule version control. Each rule carries version information, and each link unit records the rule version number it uses. When a rule is updated, it can be determined whether the old link unit needs to be rebuilt or recalculated.

[0122] Rules can be dynamically hot-loaded. New rules can be hot-updated during system operation without affecting existing caches or link reuse.

[0123] By versioning and configuring, the system can avoid "rule overfitting" and safely roll back after detecting over-normalization.

[0124] In step S2, the hash value of the canonical representation of the current task input information is matched with the key-value index in the computer system memory. The key-value index stores the direct mapping from the hash value of the canonical representation of the task input information corresponding to each link unit to the corresponding link unit.

[0125] The first match is an exact match. For standardized / templated calls, it is almost instantaneous with low latency. If the first match does not match a link unit, the process proceeds to step S3; otherwise, the process proceeds to step S5.

[0126] In step S3, if the first match fails to find a link unit, the semantic vector of the current task input information is calculated and matched with a vector library stored in the computer system's memory. The vector library stores the semantic vectors of the corresponding task input information for each link unit. If the second match fails to find a link unit, the process proceeds to step S4; otherwise, the process proceeds to step S5.

[0127] The semantic vectors of link units can also be stored using ANN indexes (such as HNSW, Faiss IVF+PQ). To reduce false positives, vector-related metadata (task type, source, timestamp) can be saved simultaneously during storage.

[0128] The `source` field describes the data source or generation source of the knowledge, function, or tool call results in this link unit (link unit). It is used to identify the source path of knowledge, functions, or tools, support credibility judgment and version control when reusing links, and be used for context determination when performing tracing, updating, or conflict resolution. The `source` field can be seen as a normalized short code extracted from Provenance for use in vector indexing.

[0129] The main types of sources include:

[0130] Source Category Example Instructions for use Knowledge Source kb:product_docs / v1.2 This indicates that the result comes from a specific version of the dataset in the knowledge base, and is used to automatically invalidate or re-index the dataset after knowledge updates. Function Source func:get_user_profile@api_v3 This indicates that the result was generated by a specific function call; it is used to trigger a link failure or re-execution when a function is upgraded or the parameter structure changes. Tool Source tool:bing_search This indicates that the result comes from an external tool or plugin call, which facilitates tracking interface changes and access control. Memory Source memory:inferred_from_session_1452 This indicates that the result comes from contextual reasoning or historical session memory, and is used to distinguish between direct external data and reasoning products. User Source user_input:manual_override This indicates that the link unit was manually modified or supplemented by the user and has a higher priority when reused.

[0131] The technical role of Source in the system includes:

[0132] - Index hierarchical control. During the ANN index retrieval phase, the index results can be pre-filtered using embedding_meta.source.

[0133] For example, only retrieve link units from the knowledge base or function calls to avoid mismatches with reasoning-type memories.

[0134] - Reuse confidence calculation. Results from different sources have different confidence levels. For example, results from tool or function calls have high accuracy, while results from memory or inference sources have higher uncertainty. When reusing results, the system can adjust the confidence threshold based on the source.

[0135] Dynamic update mechanism. When a data source (such as a knowledge base version update or function API upgrade) changes, related link units can be invalidated in batches by matching the source prefix.

[0136] The second matching process includes:

[0137] 1) When the first match fails to hit a link unit, calculate the semantic vector of the current task input information.

[0138] 2) Based on the semantic vector of the current task input information, determine a predetermined number of candidate vectors, such as the top K (e.g., K=10), by sorting them from the vector library according to semantic similarity.

[0139] 3) Perform a mixed score on the candidate vectors, where the mixed score = α * semantic similarity between the semantic vector of the current task input information and the candidate vector (semantic_sim) + β * reliability of the task result source in the link unit corresponding to the candidate vector (provenance_score) + γ * recency_score of the link unit corresponding to the candidate vector + δ * confidence of the link unit corresponding to the candidate vector, where α, β, γ and δ are the weights of semantic similarity, consistency of task result source, recency, and confidence, respectively.

[0140] Hybrid scoring (multi-factor decision-making) is the core of matching scoring decision-making in the "link reuse mechanism". It defines how to calculate a comprehensive matching score based on multi-dimensional features when multiple candidate vectors (link units) are retrieved from memory, so as to select the optimal reuse target.

[0141] Variable name: semantic_sim

[0142] Type: float ∈ [0,1]

[0143] Meaning: Semantic similarity, used to measure the semantic closeness between the current input and existing link units.

[0144] Calculation method: Calculated using vector cosine similarity.

[0145] Suppose the vector obtained from the current task input (after standardization and encoding) is:

[0146]

[0147] The vector of a candidate link unit is:

[0148] The cosine similarity between the two is then defined as:

[0149]

[0150] in Represents the dot product of two vectors; This represents the L2 norm of the input vector and link unit, with the calculated result ranging from [-1, 1]. In practical engineering, it is usually linearly mapped to the interval [0, 1] using the formula:

[0151]

[0152] Variable name: proofance_score

[0153] Type: float ∈ [0,1]

[0154] Meaning: Source credibility, used to assess whether the source of this link unit is reliable and consistent with the current task context.

[0155] Calculation method: Based on proofance metadata (such as source_id, task_type, version). For example: sources from the same source (such as the same knowledge base or the same tool version) are weighted higher; sources from older versions or low-confidence sources (such as cached inference results) are weighted lower.

[0156] Variable name: recency_score

[0157] Type: float ∈ [0,1]

[0158] Meaning: Time freshness, used to measure whether data or link units are still valid.

[0159] Calculation method: Calculated based on the difference between the timestamp and the current time. The formula is as follows:

[0160]

[0161] Where λ is the time decay coefficient, and the half-life is . ,but .

[0162] It's the time difference, calculated using the following formula:

[0163]

[0164] in The current time is in UTC (Coordinated Universal Time) format.

[0165] =embedding_meta.timestamp

[0166] For example, the time decay factor of real-time data (stocks / weather) =0.5 days, then λ≈1.386, if =0.25 days (6 hours) recency_score≈0.707, if =1 day, the score drops to approximately 0.25. The time freshness score is too low, and the data is unusable.

[0167] Variable name: confidence

[0168] Type: float ∈ [0,1]

[0169] Meaning: The confidence level of a link unit itself, reflecting its historical reuse performance and the quality of its execution results.

[0170] Calculation method: The initial value comes from the model confidence at the time of generation; it can be dynamically updated based on user feedback.

[0171] Code example for calculating semantic_sim (semantic similarity):

[0172] import numpy as np

[0173] def cosine_similarity(v_input, v_link):

[0174] v_input = np.array(v_input)

[0175] v_link = np.array(v_link)

[0176] sim = np.dot(v_input, v_link) / (np.linalg.norm(v_input) *np.linalg.norm(v_link))

[0177] # Map to [0, 1]

[0178] return (sim + 1) / 2

[0179] # Example:

[0180] v_input = [0.12, 0.33, 0.54, 0.10]

[0181] v_link = [0.11, 0.30, 0.56, 0.08]

[0182] semantic_sim = cosine_similarity(v_input, v_link)

[0183] print(round(semantic_sim, 4)) # Output 0.9873

[0184] The value 0.9873 indicates that the current input semantics are almost identical to the semantics of the link unit and can be directly reused.

[0185] Definition of parameter weights (α, β, γ, δ)

[0186] parameter meaning Range of values Adjust strategy α Semantic similarity weight [0.4 ~ 0.7] In terms of the dominant dimension, α should be increased for task understanding tasks (QA, Summarization); it can be slightly lower for function call chain reuse. β Source Consistency Weight [0.1 ~ 0.3] Increase β appropriately when the system has multiple knowledge bases or heterogeneous tasks (such as API + KB hybrid). γ Time freshness weight [0.05 ~ 0.2] Increase γ in scenarios with rapidly changing data (financial market data, real-time medical diagnosis); reduce γ for static knowledge tasks. δ Confidence weight [0.1 ~ 0.3] This indicates the importance of execution reliability; this value can be increased if the system has a strong feedback mechanism (such as online verification).

[0187] These weights can be dynamically adjusted by the system, automatically adjusted based on historical reuse accuracy or task type.

[0188] 4) If the hybrid score of a candidate vector is higher than a preset threshold (e.g., hybrid_score ≥ τ (e.g., 0.75)), then the link unit corresponding to that candidate vector is selected. If multiple candidate vectors meet the condition simultaneously, the one with the highest hybrid score is selected or the results are fused.

[0189] Suppose K candidate link units {L1…L... are hit k Their hybrid_scores are all greater than or equal to τ, and the following result fusion strategy can be adopted:

[0190] 1. Filter out unsafe candidates by first applying the "pre-reuse verification" rule:

[0191] - Check if ValidUntil has expired and if needs_revalidation is false;

[0192] - Check if the external data source reports an update;

[0193] - Check if Confidence is above the threshold.

[0194] Candidates that do not meet these conditions are directly removed from the fusion set.

[0195] 2. Select the fusion strategy according to the task type:

[0196] 2.1 If the task result is primarily a collection of knowledge / documents (KnowledgeResult):

[0197] Merge and deduplicate multiple candidate document IDs / fragments;

[0198] The merged document collection is then reordered (using the original hybrid_score or semantic_sim+recency).

[0199] When you need to generate answers for users, use LLM to read this set of documents and aggregate the answers.

[0200] 2.2 If the result is the structured output (JSON / table) of a function / tool, perform a consistency check on the same field:

[0201] If the field values ​​are highly consistent (within the tolerance range), one of the "latest / highest confidence" values ​​can be taken, or a weighted average can be calculated (the weights can be normalized to wᵢ using hybrid_score).

[0202] If there are obvious conflicts in the field values, prioritize the result with higher recency (higher recency_score) and more reliable source (higher proofance_score), and trigger re-execution when necessary instead of blindly merging.

[0203] 2.3 If the result is intermediate link information (such as the search results + function results in ExecutionTrace), only the relatively stable part (such as the search result list) can be merged, and the optimal candidate or re-execution can be selected for the volatile part (function execution results).

[0204] 3. Weighted fusion logic (example)

[0205] Define weights: ,in This refers to the mixed score of the i-th candidate vector among the candidate vectors whose mixed scores are higher than a preset threshold. The mixed score is the score of the j-th candidate vector among the candidate vectors whose mixed scores are higher than a preset threshold. The weight of the i-th candidate vector among the candidate vectors whose mixed scores are higher than a preset threshold.

[0206] Log-numeric fields: ,in This represents the result value of the link unit corresponding to the i-th candidate vector among the candidate vectors whose mixed scores are higher than a preset threshold. This represents the value of the fusion result.

[0207] For text-based fields: Feed the candidate results plus their corresponding weights to the LLM, requiring "to perform consistency checks based on the weights, merge similar content descriptions, and emphasize the parts with higher weights, more recent updates, and higher confidence levels, and mark the uncertainties."

[0208] 4. Output a new link unit. Write the fused result into a new link unit:

[0209] The ExecutionTrace records "which old link units it came from + the result fusion strategy used";

[0210] Create relationships (such as the MERGED_FROM edge) between all participating link units in the graph database.

[0211] In step S4, if the second match still fails to find a link unit, a new knowledge base retrieval, function execution, or tool call is triggered based on the current task input information. The result, along with the corresponding hash value and semantic vector, is assembled into a link unit according to the link unit structured storage model. The hash value, semantic vector, result source, and result validity period of this link unit are written into the key-value index, vector library, and graph database in the computer system's memory, respectively.

[0212] Key-value index stores a direct mapping from hash values ​​to link units based on canonical representations, enabling efficient and low-overhead precise reuse.

[0213] The vector library / ANN index stores the semantic vector representation of the link unit, supports approximate retrieval of ANN (such as HNSW / Faiss), and realizes fuzzy / semantic reuse.

[0214] The graph database stores the relationships between links, the source of task results / link unit version / validity information of task results, and audit and traceability paths (facilitating partial reuse and update reasoning).

[0215] Inter-link relationships can be generated through the following processing:

[0216] 1. Node

[0217] - Each LinkID is a graph node;

[0218] - Optional additional nodes: data source nodes (such as a knowledge base version or a function version), user / session nodes, etc.

[0219] 2. Relationship type (edge). In implementation, there will be at least several types of edges:

[0220] - VERSION_OF / PREV_VERSION. When a new version of the link unit is generated by re-authentication or incremental authentication: new node L_new ——(VERSION_OF)→ old node L_old.

[0221] - DERIVED_FROM / PARTIAL_REUSE. When only intermediate links (certain steps specified by execution_trace) are partially reused: the new link unit L_cur of the current task ——(DERIVED_FROM)→ the reused intermediate link unit L_mid.

[0222] - USES_SOURCE. Based on Provenance / source, a relationship is established between the link unit and the data source (KB version, function version, tool version) for subsequent "batch failure or recalculation when a certain source changes".

[0223] - CALL_CHAIN ​​ / NEXT_STEP. Each step in ExecutionTrace (knowledge retrieval → function → tool) can be mapped to the call relationship between link units, which helps with partial reuse and tracing.

[0224] 3. The timing of relationship formation:

[0225] - When creating a new link unit:

[0226] Based on ExecutionTrace, other link units (or abstract "external call nodes") directly called during this execution process are connected into a call chain;

[0227] Based on the current rule version and data source version, create edges such as USES_SOURCE and USES_RULE_VERSION in the graph.

[0228] - During revalidation / incremental validation / rule changes:

[0229] Create a new version link unit node and write the VERSION_OF relationship;

[0230] Update the "validity" attribute based on the detection results (in the graph, this can be used as a node attribute or edge attribute, such as valid=true / false, ttl, etc.).

[0231] By leveraging relationships between links, at least one or more of the following functions can be achieved: finding all link units that depend on a certain knowledge base version; tracing back along the call chain to find the upstream steps that cause the result deviation; and expanding outward from a high-value link unit to find similar links that can be migrated and reused.

[0232] When writing, idempotent write can be used (first check if there is already a link unit with the same specification representing the hash value, and if so, merge the traceable intermediate link (execution_trace) and version it, instead of simply overwriting).

[0233] In step S5, if the first or second match hits a link unit, the task corresponding to the current task input information is no longer executed, and the task result in the corresponding hit link unit is reused.

[0234] In this embodiment, reuse may employ one or more of the following strategies:

[0235] 1) Pre-reuse verification: After a successful reuse, the following verifications must be passed for complete reuse:

[0236] - The task result has not expired and the re-verification is marked as "false";

[0237] - External sources in the task results sources have not reported updates (as determined through change notifications or polling);

[0238] - The credibility exceeds the set threshold;

[0239] 2) Partial reuse: If the pre-reuse verification fails, it means that full reuse is not safe. The results of some intermediate links (such as knowledge retrieval results) that are indicated by the traceable field (execution_trace) in the hit link unit (which depends on fewer external time-sensitive factors) can be reused, but the function / real-time API call, etc. are re-executed.

[0240] 3) Context fusion: Before returning the reuse result, the task result in the hit link unit is matched with the current task context for difference adaptation. Based on the normalization rule level corresponding to the difference, the reuse method of the task result in the hit link unit is determined (if necessary, LLM is used for lightweight rewriting / supplementation, and the association relationship of the new link unit is written back).

[0241] The function of difference adaptation is as follows:

[0242] 1. Context alignment

[0243] The old link is the result generated under the "historical context + parameters at that time", while the current task may be different in terms of time, user identity, output format, etc.

[0244] Difference adaptation aligns these differences before reusing the results, avoiding issues such as:

[0245] - The relative time distortion of "yesterday";

[0246] - Using the wrong language / format expected by the current user;

[0247] - Referencing older terminology, rules, etc.

[0248] 2. Results of Secure Package Reuse

[0249] Even if the underlying logic is reusable, simply passing the old results to the user as is may not be appropriate. Through difference adaptation, we can add a disclaimer with the current time, supplement missing fields, and revise potentially outdated information.

[0250] Difference adaptation can be achieved through the following processing:

[0251] 1. Construct an "input difference" description

[0252] Perform a fine-grained diff between the old link unit's InputSignature / InputText and the normalized representation of the current task to identify the changes:

[0253] - Parameter differences: For example, the time range changes from "last week" to "the past 30 days";

[0254] - Contextual differences: the topic of the current conversation, user preferences, etc.;

[0255] - Format differences: The current task requires JSON output, Markdown tables, etc.

[0256] 2. Layering determines the processing method.

[0257] - If the differences are only at the tone / format level: use LLM to "reformat + style adjust" the results without changing the core facts;

[0258] - If the differences involve the parameter level but can be resolved through local patching, such as consistent statistical definitions but a longer time window: the original function call can be found in the ExecutionTrace, the same logic can be rerun in the new time range, and then the new values ​​can be filled back into the old specification template using LLM;

[0259] - If the difference touches on the task-level intent (e.g., from "generate report" to "generate summary"): the old final results are usually no longer reused, but only the intermediate retrieval / analysis results are reused, allowing the LLM to be reorganized according to the new intent.

[0260] 3. Use LLM for lightweight rewriting / supplementation if necessary. Input includes:

[0261] - Old results (KnowledgeResult / FunctionResult in the link unit);

[0262] - Difference information (old input vs. changes in fields of the current input);

[0263] - Current context (the user's latest conversation content, expected format, etc.).

[0264] The LLM prompt states: "Update, rewrite, or supplement this result as necessary based on the parameters / context of the current task without changing the facts."

[0265] 4. Write back the new link units and associations.

[0266] The new results after the difference adaptation are written as new link units, and the DERIVED_FROM / ADAPTED_FROM relationship with the original link units is established in the graph database for subsequent reuse and traceability.

[0267] All write / reuse operations in the link unit are recorded with audit entries and permission verification is performed. The execution_trace in the link unit saves the source_id and timestamp of each step so that it can be traced back when reuse fails, ensuring access control and an immutable audit chain.

[0268] In this embodiment, the link unit may use one or more of the following strategies for updating:

[0269] 1) Time-Limited Time (TTL / Task Result Validity): Each link unit has a task result validity period, which is determined at creation time based on the data type (real-time / semi-real-time / static). After the validity period of a link unit's task result expires, it can no longer be directly reused. A re-verification of the link unit's task result must be triggered, and the task result can only be reused after the re-verification is successful.

[0270] 2) Passive trigger update: If an external data source change event (webhook, message queue) is received, the revalidation flag needs_revalidation of the corresponding link unit is modified to true (revalidation is required), and the link update can be re-executed asynchronously.

[0271] 3) Proactive verification strategy: For frequently hit link units, perform incremental verification periodically (configurable) (e.g., perform small sample re-execution on the function return value to confirm consistency).

[0272] For link units deemed "high-value" (high-frequency hits, high-return, or high-risk links, such as: hit frequency >1000 within 7 days, scenarios involving money / risk / law, or manually labeled as important), the system establishes a proactive re-verification strategy (periodic / event-driven). Simultaneously, key metrics (hit rate, post-reuse error rate, user feedback rate, etc.) are monitored. When metrics are abnormal (e.g., "high hit rate but rising error rate"), automatic rollback or degradation is triggered, and an alarm is issued to operations / review personnel to ensure the system does not spread erroneous results due to outdated / erroneous links.

[0273] - High-value links: marked according to business rules (e.g., hit frequency > N, scenarios involving money / risk / law, or manually marked as important).

[0274] - Revalidation: Re-execute the chain (or critical steps) to confirm that the results are still correct / fresh. This can be categorized as: full re-execution, partial re-execution (recalculating only the function), or fast sampling verification.

[0275] Full re-execution: Re-run the entire knowledge retrieval-function-tool chain to ensure consistency with current external data. Suitable when severe drift or significant changes in the source of results are detected.

[0276] Partial re-execution: Only "high-risk" or "volatile" steps in the chain are re-executed (e.g., re-execute function calls, but no longer perform a full knowledge base retrieval), and key output fields are compared. This is suitable for most scenarios and has a moderate cost.

[0277] Fast sampling and validation: Re-examine the source of the result and perform lightweight validation functions on key fields (such as range / cell checks on numerical results), or perform non-empty, format, and range checks on the output, which is suitable for low-cost and fast judgment.

[0278] - Rollback: When re-verification fails or monitoring detects an anomaly, mark the link unit as invalid and restore it to the previous stable version or trigger re-execution and replacement.

[0279] - Monitoring and Alerts: Automatic alerts are issued based on indicator thresholds and trend detection, and automated handling strategies are supported.

[0280] 4) Incremental Replacement and Version Rollback: Create new versions for newly generated link units and retain old versions (for easy rollback and auditing). The graph database stores the version relationship chain. Based on the relationships between link units stored in the graph database, the system can retrieve related links based on graph queries to achieve cross-task migration.

[0281] This invention introduces a fusion layer (for implementing the method) and a structured link unit storage model. The fusion layer's task is to insert collection / standardization / vectorization steps between the input and output of each external retrieval of knowledge bases, functions, or tool calls, writing the results into memory in the form of "link units" (including: key-value precise indexes, vector indexes, and graph / metadata indexes). During queries, a priority strategy is adopted: first, hash precise matching → then vector semantic matching → if no match is found, execution and writing are performed. Before reuse, validity checks (TTL, version, lightweight check functions) are performed, and traceable execution paths and credibility information are recorded. In other words, when the agent receives a user task, it first checks if a relevant link unit exists in memory; if a matching input condition exists, the existing result is directly reused; if not, a new retrieval / call is executed, and the result and call parameters are stored in the system memory, forming a "traceable and reusable" knowledge-function-tool link.

[0282] This invention directly associates and structurally stores three types of "external results" generated during the operation of intelligent applications—knowledge base retrieval results, function / tool ​​call results, and call parameters (execution context)—with system memory (short-term / long-term memory; supports the reuse of historical "execution links (knowledge base → function → tool)" through precise (hash) and semantic (vector) matching, and allows for consistency and timeliness verification before reuse; supports link tracing, partial reuse (reusing intermediate links or parameters), and condition updates, reducing repeated calls and improving consistency and efficiency.

[0283] The method of the present invention has the following advantages:

[0284] - Information fusion: Breaking through the limitation of traditional memory that can only store context, it achieves deep integration of memory with knowledge, functions, and tool results.

[0285] - Link reuse: Avoid repeated retrieval or invocation, reduce system load, and improve execution efficiency.

[0286] - Consistency Enhancement: Reuse historical results to ensure consistency and stability of responses.

[0287] - Traceability: The link unit structure supports the tracing and verification of the source of results.

[0288] - Highly scalable: Adaptable to different types of knowledge bases, function libraries and external tools, supporting cross-scenario applications.

[0289] Example: A user asks "Calculate the 30-day moving average" and finds a link unit with a historical getMA(30). GetMovingAverage(30) and getMA(30) are normalized to the same signature and generate the same canonical hash value, thus achieving an exact match. If the user asks "Please help me look at the 30-day moving average," the semantic vector has a high similarity to the existing link unit, triggering semantic reuse.

[0290] In another embodiment, a computer device is provided, including a processor, a memory, and a computer program stored in the memory, wherein the processor executes the computer program to implement the steps of the method described above.

[0291] In another embodiment, a computer program product is provided, including a computer program / instructions, characterized in that the computer program / instructions, when executed by a processor, implement the steps of the method described above.

[0292] The various embodiments described herein, or their specific features, structures, or characteristics, may be suitably combined in one or more embodiments of the invention. Furthermore, in some cases, the order of steps described in the flowcharts and / or pipeline processes may be modified where appropriate, and they need not be performed in the exact order described. Additionally, various aspects of the invention may be implemented using software, hardware, firmware, or combinations thereof, and / or other computer-implemented modules or devices that perform the described functions. Software implementations of the invention may include executable code stored in a computer-readable medium and executed by one or more processors. Computer-readable media may include computer hard disk drives, ROM, RAM, flash memory, portable computer storage media such as CD-ROM, DVD-ROM, flash drives, and / or other devices having a Universal Serial Bus (USB) interface, and / or any other suitable tangible or non-transitory computer-readable medium or computer memory on which executable code can be stored and executed by a processor. The invention may be used in conjunction with any suitable operating system.

[0293] Unless otherwise expressly stated, the singular forms "a" and "the" as used herein include the plural meaning (i.e., meaning "at least one"). It should be further understood that the terms "having," "comprising," and / or "including" as used in the specification indicate the presence of the described features, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, elements, components, and / or combinations thereof. The terms "and / or" as used herein include any and all combinations of one or more of the listed related items.

[0294] The foregoing has described some preferred embodiments of the present invention. However, it should be emphasized that the present invention is not limited to these embodiments, but can be implemented in other ways within the scope of the present invention. Those skilled in the art can make various modifications and variations to the present invention based on the inventive concept and without departing from the scope of the present invention, and such modifications or variations still fall within the protection scope of the present invention.< / normalized> < / normalized>

Claims

1. A method for reusing task results, characterized in that, The method includes: The first normalized representation is obtained by normalizing the input information of the current task based on the normalization rules; Determine the semantic vector differences between the original current task input information and the first canonical representation; If the semantic vector difference exceeds a predetermined threshold, the normalization rules are rolled back or adjusted, and the current task input information is re-normalized to obtain a second normalized representation; Calculate the hash value represented by the first or second specification; The hash value is matched with the key-value index in the computer system memory. The key-value index stores the direct mapping from the hash value of the canonical representation of the task input information corresponding to each link unit to the corresponding link unit. Each link unit is a structured storage model and includes the link unit ID, the hash value of the canonical representation of the corresponding task input information, the semantic vector of the corresponding task input information, and the corresponding task result. The task is knowledge base retrieval, function execution, or tool call. If the first match fails to find a link unit, the semantic vector of the current task input information is calculated and matched with a vector library stored in the computer system's memory. The vector library stores the semantic vectors of the corresponding task input information for each link unit. The second match includes: calculating the semantic vector of the current task input information; determining a predetermined number of candidate vectors based on the semantic vector of the current task input information, sorted from the vector library according to semantic similarity; and performing a mixed score on each candidate vector, where the mixed score = α * semantic similarity between the semantic vector of the current task input information and the candidate vector + β * credibility of the task result source in the link unit corresponding to the candidate vector + γ * time freshness of the link unit corresponding to the candidate vector + δ * confidence of the link unit corresponding to the candidate vector, where α is the semantic similarity weight, β is the consistency weight of the task result source, γ is the time freshness weight, and δ is the confidence weight. If the mixed score of a candidate vector is higher than a preset threshold, then the link unit corresponding to that candidate vector is matched. If the second match still fails to find a link unit, a new knowledge base retrieval, function execution, or tool call is triggered based on the current task input information. The result, along with the corresponding hash value and semantic vector, is assembled into a link unit according to the link unit structured storage model. The hash value, semantic vector, result source, and result validity period in the link unit are written into the key-value index, vector library, and graph database in the computer system's memory, respectively, for matching during subsequent reuse. If the first or second match hits a link unit, the task corresponding to the current task input information will no longer be executed, and the task result in the hit link unit will be reused.

2. The method according to claim 1, characterized in that, The normalization process includes one or more of the following: Sort the parameters in the current task input information so that inputs of the same function with different parameter orders have the same representation; Unify the aliases of functions, fields, and / or units in the current task input information to the standard names; Unify the physical quantities or units of quantity in the current task input information to standard units; Explicitly complete the default parameters omitted in the current task's input information; Perform context trimming on the current task input information to remove context noise fields that are irrelevant to the task; The processed current task input information is serialized according to a fixed field order to obtain a standardized representation of the current task input information.

3. The method according to claim 2, characterized in that, The context clipping includes one or more of the following: Determine the semantic relevance between each context field in the current task input information and the task body, and retain only the highly relevant context fields; Prune fields in the current task input information that have low variation between similar tasks with semantic vector similarity greater than a preset threshold; Remove time- or status-sensitive fields from the current task's input information; Limit the size of the context window involved in the normalization process.

4. The method according to claim 1, characterized in that, The task result of multiplexing the hit link unit includes one or more of the following processes: The validity period, source and credibility of the task results of the hit link unit are verified, and the results can only be fully reused after passing the verification. If the verification fails, only the results of the intermediate links indicated by the traceable fields in the hit link unit can be reused, and the remaining links can be re-executed. Before returning the reuse result, the task result in the hit link unit is matched with the current task context for difference adaptation. Based on the normalization rule level corresponding to the difference, the reuse method of the task result in the hit link unit is determined.

5. The method according to claim 1, characterized in that, The update of the link unit includes one or more of the following: If the validity period of the task result of a link unit expires, a re-verification is triggered and the re-verification is successful before the task result can be reused. If an external data source change event is received, the re-authentication flag of the corresponding link unit will be modified to indicate that re-authentication is required. For link units that are frequently hit, incremental verification should be performed periodically.

6. The method according to claim 5, characterized in that, For newly generated link units after re-verification or incremental verification, a new version is created while the old version is retained, and the version relationship chain is stored.

7. A computer device, comprising a processor, a memory, and a computer program stored in the memory, characterized in that, The processor executes the computer program to implement the steps of the method according to any one of claims 1-6.

8. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method described in any one of claims 1-6.

Images