Intelligent agent-oriented shared knowledge assembly method, electronic device, and storage medium

Abstract

The present disclosure relates to a shared knowledge assembly method for intelligent agents, an electronic device and a storage medium. The method comprises: obtaining user request identification information associated with a user request; generating an assembly context object bound to the user request based on the user request identification information, the assembly context object containing a request scope representing a level to which the user request belongs; screening candidate knowledge objects from a shared knowledge base that match the request scope and are related to the query content of the user request; generating a shared context for the user request based on the candidate knowledge objects; and injecting the shared context into a memory context block independent of a system prompt word, and constructing a message sequence corresponding to the user request based on the system prompt word, the memory context block and the query content. The embodiment method provides shared knowledge reuse for intelligent agents, improving multi-user collaboration efficiency.

Description

Technical Field

[0001] This disclosure relates to the field of artificial intelligence agent technology, and more specifically, to a method for assembling shared knowledge for intelligent agents, an electronic device, and a non-transitory computer-readable storage medium. Background Technology

[0002] As intelligent agent systems are increasingly used in team collaboration scenarios, the need for multiple users to continuously interact around the same project or code repository is constantly growing. Existing intelligent agent systems typically rely on single-user sessions as the primary source of context, causing different users to repeatedly explain the same project background, architectural relationships, and operational guidelines to the intelligent agent within their respective sessions, resulting in significant token consumption and time costs. Summary of the Invention

[0003] One objective of this disclosure is to provide a technical solution for intelligent agents to reuse shared knowledge, thereby improving the efficiency of multi-user collaboration.

[0004] According to a first aspect of this disclosure, a According to a second aspect of this disclosure, an electronic device is also provided, the electronic device comprising: At least one processor; and A memory that is communicatively connected to the at least one processor; The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method according to the first aspect of this disclosure.

[0005] According to a third aspect of this disclosure, a non-transitory computer-readable storage medium is also provided, the non-transitory computer-readable storage medium storing computer instructions for causing the computer to perform the method according to the first aspect of this disclosure.

[0006] In this embodiment, the assembly context object includes a request scope representing the level to which the user request belongs, while the knowledge objects in the shared knowledge base are marked with a shared scope to limit their visibility. By matching the request scope corresponding to the user request with the shared scope of the knowledge objects in the shared knowledge base, it can be ensured that each user request can only access the knowledge objects they are authorized to view, effectively preventing the leakage of sensitive information and data pollution across teams or projects. Moreover, this embodiment maintains the static stability of the system prompts across multiple user requests by injecting the shared context into a memory context injection block independent of the system prompts, rather than directly modifying the system prompts themselves. In this way, the prefix caching mechanism of the large language model inference service can still effectively reuse the cached system prompts, and the dynamic changes of the shared context will not destroy the cache validity. Thus, while improving the knowledge sharing efficiency in multi-user collaborative scenarios, the technical benefits of the original cache optimization mechanism are maintained.

[0007] The features and advantages of the embodiments of this specification will become clear from the following detailed description of exemplary embodiments with reference to the accompanying drawings. Attached Figure Description

[0008] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments of this specification and, together with their description, serve to explain the principles of these embodiments.

[0009] Figure 1 These are schematic diagrams illustrating application scenarios that can be used in the embodiments of this disclosure; Figure 2 This is a flowchart illustrating a shared knowledge assembly method based on some embodiments; Figure 3 This is a flowchart illustrating the process of generating a shared context for a user request based on candidate knowledge objects, according to some embodiments. Figure 4 This is a process for adding knowledge objects to a shared knowledge base according to some embodiments; Figure 5 This is a schematic diagram of the composition structure of an intelligent agent system according to some embodiments; Figure 6 This is a schematic diagram of the hardware structure of an electronic device according to some embodiments. Detailed Implementation

[0010] Various exemplary embodiments of this specification will now be described in detail with reference to the accompanying drawings.

[0011] The following description of at least one exemplary embodiment is merely illustrative and is in no way intended to limit the embodiments of this specification or their application or use.

[0012] It should be noted that similar labels and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be discussed further in subsequent figures.

[0013] It should be noted that all data acquisition actions in this disclosure were carried out in compliance with the relevant data protection laws and policies of the country where the data is located, and with the authorization of the relevant equipment owner.

[0014] This disclosure relates to the field of artificial intelligence technology, specifically to a shared knowledge assembly method in an intelligent agent system. This method is applicable to complex interaction scenarios involving multiple sessions, multiple users, multiple projects, and / or multiple teams, enabling efficient retrieval, dynamic assembly, and context injection of shared knowledge to improve the response quality and reasoning efficiency of the intelligent agent system.

[0015] Figure 1 This is a schematic diagram illustrating the structural composition of an intelligent agent system that can apply the technical solutions provided in the embodiments of this disclosure. For example... Figure 1 As shown, the intelligent agent system 1000 may include an intelligent agent client 1100, a request processing system 1200, a reasoning service system 1300, and a shared knowledge base 1400.

[0016] The intelligent agent client 1100 runs on a user terminal and is used to interact with the user. The user terminal can be any of a smartphone, tablet, personal computer, laptop, workstation, or dedicated interactive terminal. The intelligent agent client 1100 can be any of a local application, web application, or mini-program application. The intelligent agent client 1100 receives query content in natural language form input by the user, and generates a user request based on the query content, user identifier, and session identifier. It then uses the communication capabilities of the user terminal to send the user request to the request processing system 1200.

[0017] The request processing system 1200, the reasoning service system 1300, and the shared knowledge base 1400 can be deployed on different physical devices or on the same physical device; any one of these systems can also be distributed and deployed on multiple physical devices, and this disclosure does not limit this.

[0018] The request processing system 1200 receives user requests sent by the intelligent agent client 1100, retrieves candidate knowledge objects open to the user request from the shared knowledge base 1400 according to the user request, and generates a shared context corresponding to the user request based on the candidate knowledge objects. The request processing system 1200 can also assemble system prompts, shared context, session continuity information of the current session, and query content into a message sequence, encapsulate the message sequence into a service request, and send the service request to the inference service system 1300.

[0019] The inference service system 1300 is equipped with at least one large language model, which is used to receive service requests sent by the request processing system 1200, call the large language model to perform inference based on the message sequence carried by the service request, generate a response, and return the generated response to the intelligent agent client 1100, which then displays it to the user.

[0020] The shared knowledge base 1400 is used to store knowledge objects that can be shared by different users within the same tenant, distinguishing between different tenants. Different users can belong to the same project or team, or to different projects or teams. The knowledge objects stored in the shared knowledge base 1400 are marked with a shared scope. The shared scope is used to declare the team and / or project level that can share the knowledge object, so as to support the request processing system 1200 in performing scope matching during retrieval.

[0021] The following is combined with Figure 1 The intelligent agent system 1000 shown illustrates various embodiments of this disclosure.

[0022] <First Embodiment> Figure 2 A flowchart illustrating a shared knowledge assembly method according to some embodiments is shown. This method can be... Figure 1 The request processing system 1200 is implemented in the system. For example... Figure 2 As shown, the method of this embodiment may include the following steps S210 to S250.

[0023] Step S210: Obtain the user request identifier information associated with the user request.

[0024] The request processing system 1200 receives user requests sent by the intelligent agent client 1100. The user request may carry a user identifier (user_id) and a session identifier (session_id), and obtains the user request identifier information associated with the user request. The user request identifier information represents the level to which the user request belongs.

[0025] In addition to the session identifier (session_id) and user identifier (user_id) carried in the user request, the user request identification information may also include at least some of the project identifier (project_id), team identifier (team_id), and tenant identifier (tenant_id) to determine the tenant level, team level, and / or project level to which the user request belongs.

[0026] The session identifier (session_id) identifies the runtime instance of the current interaction and is dynamically generated by the session management system when the session is created; the user identifier (user_id) identifies the user subject that initiated the request and is issued by the identity authentication system; the project identifier (project_id) identifies the project subject to which the current user request belongs and is issued when the project is created; the team identifier (team_id) identifies the team subject to which the current user request belongs and is issued when the team is created; and the tenant identifier (tenant_id) identifies the tenant subject to which the current user request belongs and is issued when the tenant registers.

[0027] For example, user request identification information includes session ID (session_id), user ID (user_id), project ID (project_id), team ID (team_id), and tenant ID (tenant_id). The request processing system 1200 can obtain the project ID (project_id), team ID (team_id), and tenant ID (tenant_id) based on the user ID (user_id) carried in the user request to form complete user request identification information. In one instance, the user request identification information is represented as readable_scopes = [tenant_companyA, team_backend, project_payment, user_wang, session_001], representing that the user request belongs to session 001, user wang, project payment, team backend, and tenant companyA.

[0028] Step S220: Based on the user request identification information, generate an assembly context object bound to the user request. The assembly context object contains the request scope representing the level to which the user request belongs.

[0029] The assembly context object is a structured boundary description object generated on the spot for the current user request. Its lifecycle corresponds to the processing flow of the current user request. After the request is processed, the assembly context object completes its mission and is not persisted for reuse in other user requests.

[0030] In some examples, the assembly context object contains a request scope that is at least indicated by user request identification information.

[0031] In other examples, in addition to user request identification information, the scope of the request may also include the sharing permission information of the user request, which indicates the sharing permission restrictions of the user request, and is used to further restrict the conditions for matching knowledge objects in the shared knowledge base based on the user request identification information.

[0032] Step S230: Select candidate knowledge objects from the shared knowledge base that match the shared scope and the requested scope and are related to the query content requested by the user.

[0033] In this embodiment, the shared knowledge base is used to store knowledge objects that can be shared by different users of the same tenant. The knowledge objects stored in the shared knowledge base are marked with a shared scope to limit their visibility.

[0034] When filtering candidate knowledge objects from the shared knowledge base, the first step is to perform hard filtering of the knowledge objects in the shared knowledge base using access control lists based on the assembly context object. That is, the shared scope of the knowledge object is compared with the requested scope in the assembly context object to determine if there is any overlap. If there is overlap, the knowledge object passes the hard filtering and enters the candidate knowledge object set; if there is no overlap, it is discarded directly and does not proceed to any subsequent process.

[0035] For example, if the access control list of knowledge object A allows reading of shared scopes such as tenant-companyA, team-backend, and project-payment, which overlaps with the requested scope indicated by the assembly context object, then it passes hard filtering; if the access control list of knowledge object B allows reading of shared scopes such as tenant-companyA, team-backend, and project-risk, which does not overlap with the requested scope indicated by the assembly context object, then it is discarded; if the access control list of knowledge object C allows reading of shared scopes including sensitivity L3, while the requested scope indicated by the assembly context object restricts reading sensitivity information to sensitivity L2 and below, then it is discarded because the two do not overlap.

[0036] In these examples, hard filtering via access control lists can directly exclude knowledge objects that users are not authorized to access, preventing the mixing of knowledge across projects or teams and effectively preventing the leakage of sensitive information and cross-team data pollution.

[0037] After hard filtering via access control lists, one or more retrieval methods can be used to recall candidate knowledge objects. These methods include lexical retrieval, vector retrieval, or tag retrieval. A single retrieval method is beneficial for improving retrieval efficiency. However, a hybrid retrieval using multiple methods can recall candidate knowledge objects from different dimensions, thereby improving the coverage and accuracy of the recall.

[0038] Lexical retrieval is based on exact or fuzzy matching of text strings to perform keyword retrieval on the text content of knowledge objects. This involves segmenting the query content corresponding to the user's request into words, extracting keywords, performing an inverted index retrieval on the knowledge object text that has been hard-filtered through access control lists, and returning knowledge objects containing these keywords or their variations.

[0039] Vector retrieval converts the text content of both the query and the knowledge objects into high-dimensional vectors using an embedding model. By calculating the cosine similarity or inner product between these vectors, it retrieves the knowledge objects that are semantically closest to the query. Correspondingly, when knowledge objects are stored in a shared knowledge base, their semantic vector representations can be pre-calculated and stored. During retrieval, the current query content is converted into a semantic vector, and an approximate nearest neighbor search is performed in the knowledge object vector space, which is hard-filtered by an access control list, to return the few objects with the highest semantic similarity.

[0040] Tag retrieval is based on precise matching using structured tags pre-labeled on knowledge objects during storage. Tags are metadata attributes of knowledge objects, describing their technical field, functional type, applicable scenarios, etc., and are independent of the text content. During retrieval, tags such as technical field tags, operation type tags, and service name tags can be identified from the query content. Precise matching is then performed on the tag fields of knowledge objects that have been hard-filtered through access control lists, returning knowledge objects that match the tags.

[0041] In the hybrid retrieval example, after the three retrieval methods are executed separately, the recall results from each method are merged, and duplicate knowledge objects are removed to form a set of candidate knowledge objects. During the merging process, initial weights can be assigned to each result; for example, vector retrieval results are given a higher initial weight, and tag retrieval results are given a bonus for exact match.

[0042] Step S240: Generate a shared context for the user request based on the candidate knowledge objects.

[0043] In this embodiment, the shared context of the user request is generated based on the candidate knowledge object, which can save the user from inputting project background, architectural relationship or operation specifications in the first round of interaction. This is conducive to the reasoning service system 1300 accurately understanding the content of the user's intent and improves the efficiency of user interaction.

[0044] In some examples, the metric values ​​of candidate knowledge objects can be determined based on a preset set of metrics, and at least a portion of the candidate knowledge objects can be selected to generate the shared context requested by the user based on the metric values. For example, the top N candidate knowledge objects can be selected to generate the shared context based on the metric values, where N is a set integer. Another example is selecting candidate knowledge objects whose metric values ​​exceed a set metric threshold to generate the shared context.

[0045] The preset indicator set includes one or more indicators used to evaluate the assembly priority of the target knowledge object.

[0046] For example, this preset set of metrics includes at least a query relevance metric. This query relevance metric represents the degree of matching between the content of the knowledge object and the query content corresponding to the user's request, and is used to measure the direct answer value of the knowledge object to the current query task.

[0047] Query relevance metrics can be determined based on one or more retrieval methods. These methods can be lexical retrieval, vector retrieval, or tag retrieval. Specifically, the keyword matching degree from lexical retrieval, the semantic similarity from vector retrieval, or the type matching degree from tag retrieval can be used as the query relevance metric. Alternatively, in mixed retrieval, the average score of the keyword matching degree contributed by lexical retrieval, the semantic similarity contributed by vector retrieval, and the type matching degree contributed by tag retrieval can be used as the query relevance metric.

[0048] For example, this preset metric set includes at least a scope proximity metric. This metric indicates the degree of proximity between a knowledge object and the scope level of the user's request, and is used to prioritize the recall of knowledge objects whose source scope more closely matches the current user's request scope. The scope proximity metric value can be determined based on the scope level proximity weight; the closer the source scope level of the knowledge object is to the scope level of the current user's request, the higher the scope proximity metric value. Specifically, the proximity weight of the session layer scope is higher than that of the user layer, the user layer is higher than the project layer, the project layer is higher than the team layer, and the team layer is higher than the tenant layer. Although all knowledge objects hard-filtered through access control lists are within the scope that the current user request has access to, project-level knowledge is closer to the current query task than team-level knowledge and should be injected first.

[0049] For example, the preset metric set includes at least a freshness metric. This freshness metric represents the degree of consistency between the repository fingerprint information of a knowledge object and the repository fingerprint information associated with the user request. It is used to suppress outdated knowledge objects that may be incompatible with the version of the repository associated with the user request or that have expired from being selected to generate a shared context. The repository fingerprint information of a knowledge object can be the commit hash value from the source code repository.

[0050] In applications where the preset metric set includes freshness metrics, the assembly context object also contains the repository fingerprint information of the user request. This repository fingerprint information can be obtained in real time by the request processing system from the metadata service or configuration management database (CMDB) based on the project identifier in the user request identification information. For example, in a continuous integration / continuous deployment (CI / CD) pipeline scenario, the commit hash of the code repository of the current deployment version can be written to the CMDB. The request processing system can then query the CMDB using the project identifier to obtain this hash value as the repository fingerprint information of the user request.

[0051] The closer the repository fingerprint information of a knowledge object is to the repository fingerprint information indicated by the assembly context object, such as if they are completely identical, or if they are on the same version branch and the commits are close together, the higher the freshness metric value will be.

[0052] For example, a pre-defined set of indicators should include at least a credibility indicator. This credibility indicator represents the level of confidence in a knowledge object. Confidence can be determined based on the reliability of the knowledge object's source or the degree of its verification, and is used to prioritize the injection of shared knowledge objects that have been reviewed or originate from highly reliable channels. The credibility indicator value can be determined based on the knowledge object's ingestion path, approval status, and historical verification records. For example, the credibility indicator value of knowledge objects ingested through a standardized ingestion path is higher than that of knowledge objects ingested through a conversation-derived ingestion path, and the credibility indicator value of knowledge objects approved by humans is higher than that of automatically promoted knowledge objects, etc.

[0053] For example, the preset set of indicators should include at least a token value efficiency indicator. This token value efficiency indicator represents the value of contextual information provided by a unit token cost of a knowledge object, and is used to prioritize shared knowledge objects with higher information density under token budget constraints. The token value efficiency indicator value can be determined based on the ratio of the information value of a knowledge object to its token consumption. When the information value is the same, the lower the token consumption, the higher the token value efficiency indicator value; when the token consumption is the same, the higher the information value, the higher the token value efficiency indicator value. The information value can be determined comprehensively based on the query relevance, historical adoption rate, and the number of technical features covered by the candidate knowledge object.

[0054] For example, the preset indicator set includes at least a security risk indicator. This security risk indicator represents the degree of security risk that may arise when knowledge objects are used as a shared context, and is used to impose punitive downgrading on shared knowledge objects with potential risks in the comprehensive score. The security risk indicator value can be determined comprehensively based on the sensitivity classification result of the knowledge object, whether it passes the secret scan, whether it passes the prompt injection memory security check, and the degree of permission matching of the current user request. The higher the sensitivity of the knowledge object, the lower the degree of passing the security check, and the lower the degree of permission matching with the current requesting subject, the higher the security risk indicator value. The security risk indicator participates in the calculation with a negative weight in the comprehensive evaluation formula; the higher the security risk indicator value, the lower the comprehensive indicator value.

[0055] For example, the index value of a knowledge object can be expressed as: Score(i) = α × Rel(i,q) + β × Scope(i,q) + γ × Fresh(i,q) + δ × Trust(i) + ε × Eff(i) - ζ × Risk(i), where i represents the i-th knowledge object, q represents the user request or query task, Rel(i,q) represents the query relevance index value between knowledge object i and user request q, Scope(i,q) represents the scope proximity index value between knowledge object i and user request q, Fresh(i) represents the freshness index value of knowledge object i, Trust(i) represents the trust index value of knowledge object i, Eff(i) represents the token value efficiency index value of knowledge object i, Risk(i) represents the security risk index value of knowledge object i, and α, β, γ, δ, ε, and ζ are preset weights, and at least some of the weights can be dynamically adjusted according to the task type. For example, the weights β and γ of the scope proximity index Scope(i,q) and Fresh(i) are combined weights. In project-based query questions, the proportion of weight γ in the combined weights can be increased to enhance the recall priority of project-level knowledge objects.

[0056] In these examples, by calculating the comprehensive index value of knowledge objects through a weighted combination of multidimensional indicators, a balance can be achieved between query relevance, scope matching, freshness, credibility, token efficiency, and security, ensuring that the injected shared knowledge is both relevant to the current task and meets security and quality requirements.

[0057] In other examples, token pre-approval of the shared context can be used as a constraint to select at least a subset of candidate knowledge objects to generate the shared context requested by the user. This ensures that the actual token consumption of the shared context does not exceed the token budget limit, thereby achieving cost control while obtaining high-quality responses. In these examples, such as Figure 3 As shown, generating a shared context for a user request based on candidate knowledge objects may include the following steps S2411 to S2414: Step S2411: Obtain the token consumption of the candidate knowledge object and determine the token budget for the shared context.

[0058] The token consumption of a candidate knowledge object can be obtained from the metadata of that candidate knowledge object.

[0059] In this example, the total token budget Btotal available for the current round of dialogue can be obtained first. Based on the shared context budget proportion coefficient η, the token budget allocated to the shared context is determined as Bshared = η × Btotal. The shared context budget proportion coefficient η can range from, for example, 0.10 to 0.20, so that the cost of the shared context is lower than the cost of the repeated background it saves.

[0060] The total token budget Btotal available for the current round of dialogue can be allocated as follows: Btotal = Brecent + Bshared + Bcarry + Bheadroom, where Brecent represents the recent session context budget, Bshared represents the token budget for the shared context, Bcarry represents the token budget for the tool output, and Bheadroom represents the token budget for the model response margin.

[0061] The total token budget, Btotal, is the token budget for a single round of dialogue. It represents the maximum number of tokens allowed to be used across the entire input message sequence and model response when the current request is sent to the inference service system. The total token budget is calculated independently for each round and does not accumulate across rounds. In different rounds of the same session, the token budget allocated to the shared context may decrease as the session history length increases. The system dynamically calculates the currently available shared context token budget during each request processing round to adapt to changes in context window occupancy as the session progresses. In this way, by dynamically calculating the token budget, the assembly value of shared knowledge can be maximized while ensuring that the cost of shared context injection remains controllable.

[0062] Step S2412: Select target knowledge objects from the candidate knowledge objects whose token consumption does not exceed the token budget.

[0063] Step S2413: Determine the indicator value of the target knowledge object according to the above-mentioned preset indicator set. The indicator value represents the assembly priority of the corresponding target knowledge object for the user request.

[0064] Step S2414: Based on the metric values ​​and token consumption corresponding to the target knowledge objects, select at least some of the target knowledge objects to generate a shared context, such that the actual token consumption of the shared context does not exceed the token budget.

[0065] By selecting the target knowledge object based on its corresponding metric value and token consumption, the cost overrun and context window overflow issues caused by excessive shared knowledge injection can be avoided. Furthermore, through comprehensive evaluation of a preset metric set, the assembly value of shared knowledge is maximized under token budget constraints, improving the targeting and effectiveness of shared knowledge injection.

[0066] For example, when selecting target knowledge for generating a shared context, token consumption can be accumulated according to the target knowledge objects' metric values ​​from high to low to obtain a combination of target knowledge objects whose accumulated token consumption is closest to the token budget. The shared context is then generated based on this combination of target knowledge objects. By tiering the token budget, target knowledge objects that can be injected into the shared context can be clearly identified under the token budget constraint, ensuring that the actual token consumption of the shared context does not exceed the token budget limit.

[0067] For example, assuming a total token budget Btotal = 8000 tokens, a shared context budget ratio η = 0.15, and a shared context token budget Bshared = η × Btotal = 1200 tokens, the target knowledge object set, ranked from highest to lowest metric value, is as follows: Target knowledge object A has a metric value of 0.89 and a token consumption of 420 tokens; Target knowledge object B has a metric value of 0.82 and a token consumption of 380 tokens; Target knowledge object C has a metric value of 0.75 and a token consumption of 350 tokens; Target knowledge object D has a metric value of 0.68 and a token consumption of 290 tokens; Target knowledge object E has a metric value of 0.52 and a token consumption of 260 tokens; and Target knowledge object F has a metric value of 0.44 and a token consumption of 310 tokens.

[0068] The token accumulation process is as follows: Target knowledge object A accumulates 420 tokens, not exceeding 1200 tokens; Target knowledge object B accumulates 800 tokens, not exceeding 1200 tokens; Target knowledge object C accumulates 1150 tokens, not exceeding 1200 tokens; Target knowledge object D accumulates 1440 tokens, exceeding 1200 tokens. Therefore, the resulting combination of target knowledge objects includes target knowledge objects A, B, and C, while other target knowledge objects D, E, and F are removed.

[0069] For example, step S2414, which selects at least a portion of the candidate knowledge objects to generate a shared context based on the indicator values ​​and token consumption corresponding to the candidate knowledge objects, may also include the following steps S2414a to S2414e: Step S2414a: For each target knowledge object, determine the token cost efficiency index value of the target knowledge object based on the ratio of the token consumption to the index value of the target knowledge object.

[0070] The token cost efficiency index represents the token cost per unit index value of the corresponding target knowledge object. The smaller the token cost efficiency index, the lower the token cost per unit index value the target knowledge object obtains, and the higher its priority in being selected into the pre-assembly queue.

[0071] By using the token cost efficiency index as the basis for assembly priority, we can ensure that, within a limited token budget, the target knowledge object with the lowest unit index cost is selected first, thereby improving the information density in the shared context.

[0072] Step S2414b: Add the target knowledge object in the current order to the pre-assembly queue according to the token cost efficiency index value from low to high, and calculate the current token consumption of the pre-assembly queue after the addition is completed.

[0073] In step S2414c, if the current token consumption does not exceed the token budget, return to step S2413b and continue to assemble the target knowledge object into the pre-assembly queue.

[0074] In step S2414d, if the current token consumption exceeds the token budget, the newly added target knowledge object is removed from the pre-assembly queue according to the set removal conditions, and the pre-assembly operation ends.

[0075] In step S2414e, in response to the completion of the pre-assembly operation, a shared context is generated based on the target knowledge objects in the pre-assembly queue.

[0076] For example, step S2414, which selects at least a portion of candidate knowledge objects to generate a shared context based on the indicator values ​​and token consumption corresponding to the candidate knowledge objects, may further include the following steps: based on the indicator values ​​and token consumption corresponding to the target knowledge objects, performing semantic deduplication on the target knowledge object set whose semantic similarity exceeds a preset threshold to update the target knowledge object set; and, based on the indicator values ​​and token consumption corresponding to the target knowledge objects in the updated target knowledge object set, selecting at least a portion of the target knowledge objects from the updated target knowledge object set to generate a shared context. Semantic deduplication can eliminate information redundancy in the shared context, avoiding attentional distraction or overconfidence caused by repetitive information in large language models, thereby improving the information density of the injection block while maintaining information integrity. Furthermore, semantic deduplication can also enable the same token budget to accommodate more differentiated information content, improving the overall information carrying efficiency of the injection block.

[0077] During semantic deduplication, the semantic vector corresponding to each target knowledge object can be obtained. This semantic vector can be generated through a vectorization model when the knowledge object is added to the database and stored as metadata associated with the knowledge object. The request processing system calculates the similarity (e.g., cosine similarity) between the semantic vectors of any two target knowledge objects. If the similarity exceeds a preset threshold (e.g., 0.70, 0.8, or 0.9), it determines that the two target knowledge objects have semantic redundancy and belong to the same target knowledge object group.

[0078] When performing semantic deduplication, the target knowledge object with the highest index value or the lowest token cost efficiency index value in the target knowledge object group can be retained first, while other target knowledge objects in the target knowledge object group are removed. Alternatively, the unique content of other target knowledge objects can be merged into the retained target knowledge object, and the index value and / or token consumption of the retained target knowledge object can be updated. For updating the index value, the index value of the merged target knowledge object can be recalculated based on a preset index set; or the index value of the retained target knowledge object can be reduced according to a set attenuation coefficient as the index value of the merged knowledge object; or the average of the original index values ​​of the merged target knowledge objects can be used as the index value of the merged knowledge object, etc. It will be understood by those skilled in the art that the original index value of the retained target knowledge object can also be directly used as the index value of the merged knowledge object, and this disclosure does not limit this.

[0079] For example, target knowledge object A includes the `kubectl rollout restart` step, health check verification step, and database connection timeout troubleshooting step; target knowledge object B includes the `kubectl rollout restart` step (overlapping with target knowledge object A) and Pod status check step. After deduplication, target knowledge object A is retained, and target knowledge object B is merged into target knowledge object A, so that the merged target knowledge object A includes the `kubectl rollout restart` step, health check verification step, database connection timeout troubleshooting step, and Pod status check step.

[0080] For example, step S2414, which selects at least some candidate knowledge objects to generate a shared context based on the indicator values ​​and token consumption corresponding to the candidate knowledge objects, may further include the following step: selecting at least some candidate knowledge objects to generate a shared context according to the assembly strategy version indicated by the assembly context object based on the indicator values ​​and token consumption corresponding to the candidate knowledge objects, wherein the assembly strategy version is determined based on the user request identification information.

[0081] The assembly strategy version defines the rules for selecting candidate knowledge objects for generating shared contexts based on metric values ​​and token consumption at different scope levels. Different assembly strategy versions may employ different metric weights, different elimination criteria, or different pre-assembly mechanisms. The assembly strategy version is determined based on user request identification information.

[0082] The assembly policy version defines the assembly rules for selecting knowledge objects from candidate knowledge objects to generate shared contexts at different scope levels. Different assembly policy versions correspond to different assembly parameter configurations, which may include at least one of the following: weight allocation of each indicator in the preset indicator set, conditions for adding or removing pre-assemblies, the proportion coefficient of the token budget, and termination conditions for pre-assembly operations.

[0083] The assembly strategy version is determined based on user request identification information. The request processing system can query the strategy configuration center for the currently bound assembly strategy version of a user or team based on the user identifier or team identifier in the user request identification information. In these examples, the assembly strategy version mechanism supports the use of differentiated assembly strategies at different scope levels, improving the flexibility and adaptability of assembly.

[0084] Step S250: Inject the shared context into a memory context block that is independent of the system prompt word, and construct the message sequence corresponding to the user request based on the system prompt word, the memory context block and the query content.

[0085] The message sequence is a list of messages sent to the large language model inference service. It contains multiple independent message entries, including system prompt words, memory context blocks, and user input messages, to maintain clear content boundaries. The shared context uses memory context blocks as the message carrier during the injection phase. The memory context block can be inserted into the message sequence after the system prompt words and before the query content messages. Isolating the shared context from the system prompt words maintains the stability of the system prompt words, thus preserving the effectiveness of the prefix caching mechanism. This improves the efficiency of shared knowledge reuse while maintaining the benefits of the original caching optimization mechanism.

[0086] The memory context block, as an independent message entry in the message sequence, is used at least to carry and transmit shared context content. The memory context block exists only in the message sequence of the current round of requests; its purpose is fulfilled after the request is sent to the model, it is not persisted, and it is regenerated in the next round of requests.

[0087] In this embodiment, memory context blocks can be assembled according to a predefined paragraph structure. The predefined paragraph structure specifies the content partitioning method within the memory context block.

[0088] The predefined paragraph structure includes at least a shared context paragraph, which is used to store the shared context generated based on the candidate knowledge object.

[0089] Furthermore, to improve the response quality and context utilization efficiency of the inference service system 1300, the memory context block can also include user preference paragraphs and / or conversation continuity paragraphs. User preference paragraphs store user-level knowledge blocks associated with the current user, including but not limited to personalized information such as the user's work habits and preference configurations. Conversation continuity paragraphs store contextual continuation information for the current conversation, including key facts, confirmed items, and to-do items from the conversation history. By injecting conversation history information as independent paragraphs, the large language model can accurately grasp the progress of the current conversation without relying on external memory storage, avoiding repeated requests for confirmed information and ensuring the coherence and consistency of multi-turn dialogues.

[0090] Furthermore, to enhance the traceability and credibility of the content within the memory context injection block, the block may also include a source citation paragraph. This source citation paragraph stores source information for each paragraph within the memory context injection block, including but not limited to metadata such as source document identifier, author, version information, and timestamps. By centrally storing source information in a separate paragraph, it facilitates the large language model in including citation details when generating responses, improving the credibility and professionalism of the responses. Simultaneously, it allows users to trace and verify information after receiving responses, enhancing the system's transparency and auditability.

[0091] For example, a shared context paragraph may further include at least two sub-paragraphs to store different categories of shared context. For instance, a shared context paragraph may include a shared project context sub-paragraph and a shared team context sub-paragraph. The shared project context sub-paragraph can be used to store project-level knowledge blocks such as project architecture overview, technology stack description, and key constraints; the shared team context sub-paragraph can be used to store team-level knowledge blocks such as relevant team operation manuals, operation steps, command patterns, and troubleshooting processes.

[0092] When assembling shared contexts, knowledge objects can be categorized and grouped by paragraph. Each knowledge object serving as a shared context is assigned to its corresponding sub-paragraph based on its knowledge type and scope level. Within a paragraph, knowledge objects can be arranged from highest to lowest comprehensive index value or from lowest to highest token cost efficiency index value. Because large language models exhibit non-uniform attention distribution over input sequences, information at the beginning of the sequence typically receives higher attention weight. Placing high-priority knowledge at the beginning of a paragraph increases its probability of being effectively perceived and utilized by the model. Furthermore, when paragraph content is truncated due to budget constraints, high-value knowledge at the beginning has a higher retention probability, thus ensuring the overall quality of injected knowledge in budget-constrained scenarios.

[0093] As can be seen from steps S210 to S250, this embodiment effectively prevents the leakage of sensitive information and data pollution across teams or projects by using an assembly context object as the unified boundary for shared knowledge reading and writing. Furthermore, by injecting the shared context into an independent memory context block without modifying the system prompt, the effectiveness of the prefix caching mechanism is maintained, achieving precise control over the cost of shared knowledge injection. According to the method of this embodiment, different users will not need to repeatedly explain the project background, architectural relationships, and operating specifications to the intelligent agent in their respective sessions, which helps save token consumption and time costs.

[0094] <Second Embodiment> This embodiment provides a method for constructing a shared knowledge base. For example... Figure 4 As shown, the shared knowledge base includes a first type of knowledge objects generated from static materials and a second type of knowledge objects derived from conversation content. Different categories of shared knowledge materials undergo different processing flows to become knowledge objects in the shared knowledge base.

[0095] In this embodiment, the construction method may include the following steps S410 to S440.

[0096] Step S410: Receive shared knowledge materials and determine the source category of the shared knowledge materials.

[0097] In step S420, if the shared knowledge material is a highly confident static material, it is converted into a knowledge object through the first processing flow, and then step S440 is executed.

[0098] The first processing flow is a standardized ingestion process. It performs knowledge ingestion operations on highly reliable static materials such as README, AGENTS.md, docs, deployment guides, repo indexes, and manually maintained runbooks. This includes processing nodes such as source discovery, normalization, classification, slicing, structure extraction, shared scope allocation, sensitivity grading, knowledge object generation, and retrieval index construction. Since the first processing flow deals with highly reliable static materials whose sources are reliable and whose content has undergone manual review or standardized management, it primarily focuses on cleaning, structuring, and indexing the static materials, without requiring quality control assessments of the content itself.

[0099] Source discovery refers to automatically identifying static materials that can serve as shared knowledge sources from project repositories, document repositories, or knowledge management systems. Normalization refers to converting static materials of different formats into a unified standard format for easier subsequent processing. Classification refers to categorizing static materials into types such as architecture documents, deployment guidelines, and operation manuals based on their content type and purpose. Slicing refers to dividing long documents into several searchable knowledge blocks. Structure extraction refers to extracting structured information such as keywords, entity tags, and technical features from knowledge blocks. Shared scope assignment refers to assigning appropriate scope identifiers to static materials based on their source and content, such as project-level, team-level, or tenant-level. Sensitivity grading refers to assigning sensitivity levels to static materials based on their content sensitivity, such as public, internal, and confidential. Building a retrieval index refers to creating lexical, vector, and tag indexes for knowledge blocks to facilitate subsequent retrieval. Generating knowledge objects refers to combining related knowledge blocks into knowledge objects that can be injected.

[0100] In step S430, if the shared knowledge material is conversation content, it is promoted to a knowledge object through the second processing flow, and then step S440 is executed.

[0101] The conversation content is promoted to knowledge objects in the shared knowledge base according to the second processing flow. The second processing flow, also known as the conversation-derived ingestion path, extracts stable project facts, troubleshooting patterns, command patterns, workflow summaries, and decision record summaries from the conversation before or at the end of the conversation, and performs access assessments for quality control on the extracted content, such as secret scanning, scope compatibility checks, and contradiction detection.

[0102] The admission assessment node is a key point in the second processing flow where the extracted content undergoes quality control. Based on the admission assessment, it is determined whether the extracted content can be automatically promoted to the shared knowledge base, or whether it needs to be submitted to the approval queue for manual review.

[0103] Stable project fact extraction refers to identifying stable technical facts related to the project from the session, such as architectural components, interface definitions, and configuration parameters. Troubleshooting pattern extraction refers to summarizing troubleshooting steps and solutions for common faults from the session. Command pattern extraction refers to extracting commonly used command-line operation patterns from the session. Workflow summary extraction refers to summarizing successful workflows and operation sequences from the session. Decision record summary extraction refers to extracting important technical decisions and their rationale from the session.

[0104] Secret scanning involves detecting whether the extracted content contains sensitive credentials such as API keys, passwords, and access tokens; if so, promotion is blocked. Scope compatibility checking verifies whether the scope identifier of the extracted content is consistent with the scope of the current session, avoiding cross-scope contamination. Conflict detection checks whether the extracted content contradicts existing knowledge objects in the shared knowledge base; if contradictions exist, manual approval is required.

[0105] In addition, the second processing flow may include sensitivity classification and deduplication. Sensitivity classification refers to assigning a sensitivity level to the extracted content based on its degree of sensitivity. Deduplication refers to detecting whether the extracted content duplicates existing knowledge objects in the shared knowledge base; if duplicates are found, the content is not promoted further.

[0106] For example, if the credibility score of the extracted content is higher than a preset threshold (e.g., 0.8), the sensitivity level is public or internal, the scope compatibility check passes, no contradictions are found in the contradiction detection, and no duplicates are found in the deduplication process, then the extracted content can be automatically promoted to the shared knowledge base; otherwise, the extracted content needs to be submitted to the approval queue and wait for manual approval before it can be promoted.

[0107] Step S440: Store the knowledge object in the shared knowledge base.

[0108] In this embodiment, knowledge objects are acquired through a dual-processing workflow, which supports both the rapid construction of a shared knowledge base layer from highly reliable static materials and the extraction of high-value experiential knowledge from conversational sedimentation, taking into account both knowledge coverage and quality control.

[0109] <Third Embodiment> This embodiment provides a method for lifecycle management of knowledge objects in a shared knowledge base. In this embodiment, freshness, duration, and expiration triggers can be defined for different types of shared knowledge objects based on their source type and scope hierarchy.

[0110] Shared knowledge objects enter an active state after creation and can participate in retrieval and injection normally. When their lifespan expires, their freshness decreases, or the source material changes, the object will enter an expired or invalid state and will no longer participate in runtime retrieval. Some expired objects can be returned to an active state through re-approval.

[0111] Failure triggers include at least one of the following: repository fingerprint changes, document changes, configuration changes, knowledge conflicts, administrator revocation, and sensitivity reclassification. When an failure trigger is detected, the relevant shared knowledge object is marked as expired or invalid, and it returns to an active state after the invalid shared knowledge object is revalidated or updated.

[0112] In this embodiment, by managing the lifecycle of knowledge objects, the spread of outdated knowledge can be proactively detected and suppressed, ensuring that the knowledge objects in the shared knowledge base always remain fresh and accurate.

[0113] <Fourth Embodiment> This embodiment provides an intelligent agent system. This intelligent agent system can be used to execute a shared knowledge assembly method according to any embodiment, with each module working collaboratively to achieve efficient management and assembly of shared knowledge. For example... Figure 5 As shown, the request processing system 1200 of the intelligent agent system 1000 may include a session entry module 1201, an assembly context generation module 1202, a retrieval module 1203, a shared context generation module 1204, and an injection execution module 1205. The shared knowledge base 1400 may include a shared knowledge storage module 1401, a knowledge object ingestion module 1402, and a lifecycle management module 1403.

[0114] Different users (e.g., User A, User B, User C) initiate a session through a smart agent client running on their respective user terminals and engage in multiple rounds of dialogue interaction during the session, with each round of dialogue interaction triggering a shared knowledge assembly.

[0115] The session entry module 1201 is used to receive user requests and extract user request identification information associated with the user request. The session entry module 1201 then passes the user request identification information to the assembly context generation module 1202.

[0116] The assembly context generation module 1202 performs unified parsing and processing of user request identification information to generate an assembly context object. The assembly context object contains the request scope, repository fingerprint information, and assembly strategy version information.

[0117] The shared knowledge storage module 1401 stores structured shared knowledge objects isolated by shared scope. Each knowledge object can carry a source scope identifier, a sensitivity identifier, freshness information, and shared scope information. The source scope identifier marks the scope level to which the knowledge object belongs, the sensitivity identifier marks the sensitivity level of the knowledge object, the freshness information marks the repository fingerprint information of the knowledge object, and the shared scope information records the set of scopes that are allowed to read the knowledge object. In response to query requests from the retrieval module, the shared knowledge storage module 1401 returns knowledge objects that meet the shared scope filtering conditions.

[0118] The retrieval module 1203 performs hard filtering based on the assembly context object and uses a hybrid retrieval method to recall and output candidate knowledge objects.

[0119] The shared context generation module 1204 is used to classify candidate knowledge objects according to the token budget and filter out target knowledge objects; determine the index values ​​of target knowledge objects based on a preset index set to sort the target knowledge objects according to the assembly priority; perform semantic deduplication on the filtered target knowledge objects; pre-assemble the target knowledge objects according to the index values ​​or token cost efficiency index values ​​with the token budget as a constraint to generate a shared context, and send the shared context to the injection execution module 1205 for injection.

[0120] The injection execution module 1205 injects the shared context into a memory context block that is independent of the system prompt word, and constructs a message sequence corresponding to the user request based on the system prompt word, the memory context block and the query content, and sends it to the inference service system 1300 to execute the inference service.

[0121] The knowledge object ingestion module 1402 includes a standard ingestion module and a session-derived ingestion module, which add knowledge objects to the shared knowledge storage module 1401 based on the first processing flow and the second processing flow in the second embodiment, respectively.

[0122] The lifecycle management module 1403 manages the freshness, duration, and expiration status of shared knowledge objects, detects expiration triggers, and updates the knowledge object status. When an expiration trigger is detected, the module marks the relevant shared knowledge object as expired or invalid, and changes it back to valid status after the invalid shared knowledge object is re-validated or updated.

[0123] This embodiment achieves a complete end-to-end processing flow from user request to message sequence construction through the collaboration of various modules. Based on this intelligent agent system, the efficiency of shared knowledge reuse in multi-user intelligent agent collaboration scenarios can be improved.

[0124] <Fifth Embodiment> This disclosure also provides an electronic device, such as... Figure 6 As shown, the electronic device 600 includes at least one processor 610 and at least one memory 620 for storing a computer program. When the computer program is executed by the processor 610, it causes the electronic device 600 to perform a shared knowledge assembly method according to any embodiment of the present disclosure.

[0125] Electronic device 500 deploys the aforementioned request processing system to execute the shared knowledge assembly method; it can be a server or other types of equipment.

[0126] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0127] This disclosure may be a system, method, and / or computer program product. A computer program product may include a computer-readable storage medium having computer-readable program instructions loaded thereon for causing a processor to implement any of the methods in the foregoing embodiments of this disclosure.

[0128] Computer-readable storage media can be tangible devices capable of holding and storing instructions for use by an instruction execution device. Computer-readable storage media may include, for example, electrical storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination thereof. More specific examples (a non-exhaustive list) of computer-readable storage media include: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), static random access memory (SRAM), compact disc-read-only memory (CD-ROM), digital versatile disc (DVD), memory sticks, floppy disks, mechanical encoding devices, such as punch cards or recessed protrusions storing instructions thereon, and any combination thereof. The computer-readable storage medium used herein is not to be interpreted as a transient signal itself, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses through fiber optic cables), or electrical signals transmitted through wires.

[0129] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include one or more of copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to computer-readable storage media in the respective computing / processing device.

[0130] The computer program instructions used to perform the operations of this disclosure may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source or object programs written in any combination of one or more programming languages, including object-oriented programming languages ​​(such as Smalltalk, C++, etc.) and conventional procedural programming languages ​​(such as the "C" language or similar programming languages). The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network (e.g., a local area network or a wide area network), or it may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays, or programmable logic arrays, can execute computer-readable program instructions to implement various aspects of the embodiments of this disclosure by utilizing state information from the computer-readable program instructions.

[0131] Various aspects of this disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus, and computer program products according to embodiments of this disclosure. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0132] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0133] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions that execute on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0134] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction containing one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions. It should be noted that implementation in hardware, implementation in software, and implementation using a combination of software and hardware are all equivalent.

[0135] The various embodiments of this disclosure have been described above. These descriptions are exemplary and not exhaustive, and are not limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical application, or improvement of the technology in the market, or to enable others skilled in the art to understand the embodiments disclosed herein. The scope of this disclosure is defined by the appended claims.

Claims

1. A method for assembling shared knowledge for intelligent agents, characterized in that, include: Obtain the user request identifier information associated with the user request; Based on the user request identification information, an assembly context object bound to the user request is generated; wherein, the assembly context object contains a request scope indicating the level to which the user request belongs; Candidate knowledge objects are selected from the shared knowledge base whose shared scope matches the requested scope and are related to the query content requested by the user; wherein, the shared knowledge base is used to store knowledge objects that can be shared by different users, and the knowledge objects stored in the shared knowledge base are marked with a shared scope to limit the visibility range; Generate the shared context of the user request based on the candidate knowledge objects; The shared context is injected into a memory context block independent of the system prompt word, and a message sequence corresponding to the user request is constructed based on the system prompt word, the memory context block, and the query content.

2. The method according to claim 1, characterized in that, The step of generating the shared context for the user request based on the candidate knowledge objects includes: Obtain the token consumption of the candidate knowledge objects and determine the token budget for the shared context; Select target knowledge objects from among the candidate knowledge objects whose token consumption does not exceed the token budget; The indicator value of the target knowledge object is determined according to a preset indicator set; wherein, the indicator value represents the assembly priority of the corresponding target knowledge object for the user request; Based on the metric value corresponding to the target knowledge object and the token consumption, at least a portion of the target knowledge objects are selected to generate the shared context, such that the actual token consumption of the shared context does not exceed the token budget.

3. The method according to claim 2, characterized in that, The step of selecting at least a subset of target knowledge objects to generate the shared context based on the indicator value and token consumption corresponding to the target knowledge object includes: For each target knowledge object, the token cost efficiency index value of the target knowledge object is determined based on the ratio of the token consumption to the index value of the target knowledge object. According to the token cost efficiency index value from low to high, the target knowledge object in the current order is added to the pre-assembly queue, and the current token consumption of the pre-assembly queue is calculated after the addition is completed. If the current token consumption does not exceed the token budget, then continue to perform the operation of adding the target knowledge object in the current order to the pre-assembly queue; If the current token consumption exceeds the token budget, the latest added target knowledge object is removed from the pre-assembly queue, and the pre-assembly operation ends. In response to the completion of the pre-assembly operation, the shared context is generated based on the target knowledge objects in the pre-assembly queue.

4. The method according to claim 2, characterized in that, The step of selecting at least a subset of target knowledge objects to generate the shared context based on the indicator value and token consumption corresponding to the target knowledge object includes: Based on the indicator value and token consumption corresponding to the target knowledge object, semantic deduplication is performed on the target knowledge object group in the target knowledge object set whose semantic similarity exceeds a preset threshold, so as to update the target knowledge object set. Based on the indicator values ​​and token consumption corresponding to the target knowledge objects in the updated target knowledge object set, at least a portion of the target knowledge objects are selected from the updated target knowledge object set to generate the shared context.

5. The method according to claim 2, characterized in that, The step of selecting at least a subset of candidate knowledge objects to generate the shared context based on the indicator values ​​and token consumption corresponding to the candidate knowledge objects includes: Based on the metric values ​​corresponding to the candidate knowledge objects and the token consumption, at least some candidate knowledge objects are selected to generate the shared context according to the assembly strategy version indicated by the assembly context object; wherein, the assembly strategy version is determined based on the user request identification information.

6. The method according to any one of claims 2 to 5, characterized in that, The preset set of indicators includes at least one of the following: query relevance indicator, scope proximity indicator, freshness indicator, credibility indicator, token value efficiency indicator, and security risk indicator. The query relevance index represents the degree of matching between the knowledge object and the query content; the scope proximity index represents the degree of proximity between the source scope of the knowledge object and the requested scope in the assembly context object; the freshness index represents the degree of consistency between the repository fingerprint information of the knowledge object and the repository fingerprint information indicated by the assembly context object; the credibility index represents the confidence level of the knowledge object; the token value efficiency index represents the context information value per unit token cost of the knowledge object; and the security risk index represents the degree of security risk that may be caused when the knowledge object is used as a shared context.

7. The method according to any one of claims 1 to 5, characterized in that, The user request identification information includes at least some of the following identifiers: project identifier, team identifier, and tenant identifier.

8. The method according to any one of claims 1 to 5, characterized in that, The shared knowledge base includes a first type of knowledge objects generated from static materials and a second type of knowledge objects derived from conversation content; In this process, the static materials are converted into knowledge objects in the shared knowledge base through a first processing flow; the conversation content is promoted to knowledge objects in the shared knowledge base according to a second processing flow, which includes an admission assessment node for quality control.

9. An electronic device, characterized in that, include: At least one processor; as well as A memory that is communicatively connected to the at least one processor; The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-8.

10. A non-transitory computer-readable storage medium, characterized in that, The non-transitory computer-readable storage medium stores computer instructions for causing the computer to perform the method of any one of claims 1-8.

Images