Intelligent query method and system for aggregate supply chain based on business fact constraints

Abstract

The application relates to the technical field of data processing and artificial intelligence, and provides an aggregate supply chain intelligent query method and system based on business fact constraints, which solves the problem that the accuracy and reliability of intelligent query results are low due to the lack of business fact constraints in the prior art. The method comprises the following steps: obtaining a natural language query request, identifying a business intent, and extracting a structured slot; determining whether the structured slot meets a completeness condition; if not, calling a master data read-only tool to obtain a candidate list, obtaining a confirmation result of user feedback based on the candidate list, and updating the structured slot according to the confirmation result; if yes, matching a target query tool and generating a tool calling request; obtaining current state information of a target business data snapshot and determining whether an availability condition is met; if yes, reading business fact data and outputting a query result through the target query tool, otherwise, aborting the query and returning a state exception prompt.

Description

Technical Field

[0001] This application relates to the fields of data processing and artificial intelligence technology, specifically to an intelligent query method and system for aggregate supply chain based on business fact constraints. Background Technology

[0002] With the digitalization of the construction industry and bulk building materials transactions, aggregate supply chain companies need to manage massive amounts of data, including mine information, specifications, price versions, freight costs, and approval records. Current technologies supporting data querying primarily include traditional ledger entry, general ERP systems, and intelligent question-answering solutions based on large language models. However, in the strongly business-fact-constrained scenario of the aggregate supply chain, existing intelligent question-answering solutions typically generate SQL statements directly or rely on unstructured knowledge base retrieval, lacking hard constraints on business facts such as price versions, tenant boundaries, and current view status. This can easily lead to the model exposing the underlying database structure, generating unauthorized queries, or fabricating price and freight data that does not conform to the current business status. Furthermore, existing systems often lack closed-loop verification between data writing and reading, including approval governance and the current state view. This makes it difficult to guarantee that natural language query results originate from governed and accurate facts, failing to meet companies' requirements for data consistency and decision credibility. Summary of the Invention

[0003] To address the issue of low accuracy and reliability of existing intelligent query results due to a lack of business fact constraints, this application proposes an intelligent query method and system for aggregate supply chain based on business fact constraints. This method strictly restricts natural language queries to the scope of governed business facts and pre-registered tools, ensuring the authenticity and security of query results.

[0004] To achieve the above objectives, this application adopts the following technical solution: A smart query method for aggregate supply chain based on business fact constraints includes: Obtain the user's input natural language query request, identify the business intent, and extract the corresponding structured slots; Determine whether the structured slots meet the preset completeness conditions; If the condition is not met, the pre-registered master data read-only tool is invoked to obtain the corresponding candidate list, the user feedback confirmation result is obtained based on the candidate list, and the structured slot is updated according to the confirmation result until the completeness condition is met. If the conditions are met, the target query tool is matched from the pre-registered read-only tool set based on the business intent, and a tool call request is generated based on the parameter template of the target query tool. Based on the tool call request, obtain the current status information of the target business data snapshot corresponding to the target query tool, and determine whether the current status information meets the preset availability conditions; If the conditions are met, business fact data is read from the target business data snapshot and queried using the target query tool, and the query results are output; if the conditions are not met, the query is stopped and a status error message is returned.

[0005] The above solution links natural language understanding, slot completeness verification, master data clarification, read-only tool matching, and data snapshot status verification into a closed loop, forcing intelligent queries to be executed based on explicit user confirmation and available business fact snapshots. This blocks the path for the model to directly access the underlying data or generate speculative results based on expired / invalid states from the architectural level, ensuring that the query results strictly come from the governed current state business facts.

[0006] As one implementation, obtaining the confirmation result from the user feedback based on the candidate list and updating the structured slot according to the confirmation result includes: Calculate the confidence score for each of the structured slots, and mark the structured slots with confidence scores lower than a preset threshold as slots to be clarified; Invoke the master data read-only tool corresponding to the slot to be clarified to obtain the candidate list containing multiple candidate business objects; Based on the candidate list, the user feedback confirmation result is obtained, and the candidate business object corresponding to the confirmation result is used as the high confidence slot value and updated to the structured slot.

[0007] This implementation transforms ambiguous natural language references into precise business object references through confidence quantification and controlled master data tool calls, avoiding probabilistic guessing by the model when slots are missing or ambiguous, and ensuring the determinism of subsequent query parameters.

[0008] As one implementation, the step of matching a target query tool from a pre-registered set of read-only tools based on the business intent, and generating a tool invocation request based on the parameter template of the target query tool, includes: Based on the business intent, the target query tool is matched from the read-only tool set using an intent classifier combined with regular expressions; wherein, the business intent includes at least one of price quote query, freight query, specification filtering, multi-mine price comparison, and landed cost calculation; The structured slots are mapped to the parameter template of the target query tool; wherein, the structured slots include business entity dimensions, spatial node dimensions, and business indicator dimensions, and the parameters in the parameter template correspond one-to-one with the structured slots; The parameters in the parameter template are subjected to secondary validation for type, valid range and required fields. After the validation is successful, the tool call request is generated.

[0009] This implementation limits the model's tool invocation capabilities through predefined intent-tool mapping relationships and strict parameter template validation, preventing illegal parameter injection or unexpected tool combinations, and ensuring that query requests conform to the backend interface's specification definition.

[0010] As one implementation method, determining whether the current state information meets preset availability conditions includes: Extract the view refresh status and last refresh time from the current status information; wherein, the view refresh status includes active status, refreshing status, failed status, and uninitialized status; If the view refresh status is the active status, and the difference between the last refresh time and the current time is within a preset validity period, then the current status information is determined to meet the availability condition. If the view refresh status is in the refresh process, failed, or uninitialized state, or if the difference between the last refresh time and the current time exceeds the preset validity period, then the current status information is determined not to meet the availability condition.

[0011] This implementation establishes a robust health check mechanism for business data snapshots, ensuring that intelligent queries can only read fresh, complete, and stable data views, effectively preventing pricing distortion caused by data refresh delays or failures.

[0012] As one implementation method, the step of suspending the query and returning a status error message includes: Generate a status error message containing a standardized error code, error description, and suggested operation information; wherein the standardized error code includes at least one of view expiration, view refresh in progress, or view refresh failure; The abnormal status message is passed through to the front end for display, and the system-level hard rejection and prompt word constraints jointly prohibit the pre-configured large language model from generating speculative query results based on historical version data or contextual reasoning.

[0013] This implementation eliminates the possibility of the model "faking answers" when the view is unavailable, and replaces the model's soft fault tolerance with a system-level hard rejection mechanism, ensuring the absolute rigor of business decision data.

[0014] As one implementation method, the generation of the target business data snapshot includes: Obtain business fact data that has been verified and approved by the rule governance engine; wherein, the rule governance engine verification includes required field verification, enumeration range verification, numerical range verification, semantic uniqueness fingerprint verification, and cross-field dependency verification; A unique refresh batch identifier is generated based on the aforementioned business fact data; The business fact data and the refresh batch identifier are refreshed to the target business data snapshot using an atomic batch method, and the current status information is updated after the refresh is completed.

[0015] This implementation method constructs a governance closed loop from data writing to query reading, ensuring that every piece of data in the target business data snapshot has undergone multi-dimensional compliance verification and approval, and that the refresh process is atomic and traceable, providing a reliable data foundation for intelligent queries.

[0016] As one implementation method, the semantic uniqueness fingerprint verification includes: concatenating the mine identifier, specification identifier and price version in the business fact data to calculate the hash value as the semantic fingerprint, querying whether the same semantic fingerprint already exists, and if it exists, determining it as a duplicate submission and failing the verification; The cross-field dependency validation includes: checking the logical consistency between different fields in the business fact data; if there is a conflict, the validation fails. The rule governance engine adopts a short-circuit execution strategy: if any rule fails the verification, the execution of subsequent rules is immediately terminated and the writing is blocked. The failure reason is generated and stored in a structured manner. The failure reason includes the rule key, rule description, failure field and expected value.

[0017] This implementation solves the common problems of duplicate submissions and logical conflicts in traditional data entry by using semantic fingerprint deduplication and cross-field logical verification. Combined with short-circuit execution strategy, it improves verification efficiency and makes error feedback more accurate, further consolidating data quality.

[0018] As one implementation, after the parameter template generation tool call request based on the target query tool, the method further includes: The API client's key is used to perform an HMAC signature on the tool call request. The backend service verifies the validity of the HMAC signature after receiving the tool call request. The HMAC signature includes the request method, path, timestamp, parameters, and user identifier. The user identifier field and the resource scope identifier field are injected into the request header of the tool call request. The backend service performs user isolation and permission verification based on the user identifier field and the resource scope identifier field.

[0019] This implementation achieves dual security isolation at the tool invocation layer, which not only prevents requests from being tampered with or replayed, but also ensures that intelligent queries can only access data within the current user's tenant boundaries and authorized scope, eliminating the risk of unauthorized queries.

[0020] As one implementation method, the step of querying using the target query tool and outputting query results includes: The query results are subjected to multi-level output filtering; wherein, the multi-level output filtering includes: removing the database internal primary key, the user identifier, API signature, trace code, underlying table name and original SQL fragment; removing the debug stack and internal error code; and formatting numerical data according to preset business rules; The filtered query results and execution process status information are output in stages by sending events via a streaming server; wherein, the query results are incremental response text, and the execution process status information includes intent recognition status, slot filling progress, tool invocation status, view verification status, and audit summary.

[0021] This implementation method, through output anonymization and streaming transparent interaction, not only protects sensitive information within the system from being leaked, but also allows users to perceive the execution trajectory and intermediate states of intelligent queries in real time, thereby improving the trustworthiness and explainability of human-computer interaction.

[0022] Furthermore, this application also provides an intelligent query system for aggregate supply chain based on business fact constraints, used to implement the intelligent query method for aggregate supply chain based on business fact constraints as described above, including: The Natural Language Understanding module is used to acquire natural language query requests input by users, identify business intent, and extract corresponding structured slots; The slot completeness judgment module is used to determine whether the structured slot meets the preset completeness conditions. The candidate clarification module is used to, if the structured slot does not meet the completeness condition, call the pre-registered master data read-only tool to obtain the corresponding candidate list, obtain the user feedback confirmation result based on the candidate list, and update the structured slot according to the confirmation result until the completeness condition is met. The tool matching and request generation module is used to match a target query tool from the pre-registered read-only tool set based on the business intent if the structured slot meets the completeness condition, and generate a tool call request based on the parameter template of the target query tool. The snapshot status verification module is used to obtain the current status information of the target business data snapshot corresponding to the target query tool based on the tool call request, and to determine whether the current status information meets the preset availability conditions. The query execution and output module is used to read business fact data from the target business data snapshot and perform a query through the target query tool if the current status information meets the availability conditions, and output the query results; if the current status information does not meet the availability conditions, the query is stopped and a status error message is returned.

[0023] Beneficial effects: The intelligent query method and system for aggregate supply chain based on business fact constraints provided in this application constructs a rigid query link of "intent recognition - slot clarification - tool constraint - snapshot verification," strictly limiting the capabilities of the large language model to a pre-registered read-only tool set, fundamentally eliminating the risk of the model directly generating SQL or fabricating business data. By introducing a current status information verification mechanism for target business data snapshots, a hard rejection principle of "query terminated if no available snapshot" is established, ensuring that the intelligent query results necessarily originate from approved and valid business facts, significantly improving the accuracy and credibility of key data such as quotations and freight rates in aggregate supply chain scenarios. Through HMAC signatures, tenant isolation, and multi-layer output filtering, end-to-end security control is achieved from request initiation to result rendering, effectively preventing the leakage of sensitive information and unauthorized access. By sending events through a streaming server to output execution process status information in stages, the transparency and traceability of the intelligent query process are enhanced, improving the user's interactive experience in complex business analysis tasks. Attached Figure Description

[0024] Figure 1 A flowchart illustrating an intelligent query method for aggregate supply chain based on business fact constraints, provided for an embodiment of this application; Figure 2 A schematic diagram illustrating the process of candidate clarification and parameter verification provided in the embodiments of this application; Figure 3 A flowchart illustrating the data snapshot status availability verification provided in this application embodiment; Figure 4 This is a flowchart illustrating the handling of abnormal data snapshot states provided in an embodiment of this application. Figure 5 This is a system architecture diagram of an intelligent query system for aggregate supply chain based on business fact constraints, provided for an embodiment of this application. Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application.

[0026] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains.

[0027] Example 1 like Figure 1 As shown, this embodiment provides an intelligent query method for aggregate supply chain based on business fact constraints. This method constructs a rigid link from natural language understanding to business fact query, ensuring that the query results strictly originate from the managed current state data. Specifically, the method includes the following steps.

[0028] Step S100 involves acquiring the user's natural language query request, identifying the business intent, and extracting the corresponding structured slots. Specifically, the system receives raw text input by the user through a dialog interface or API interface. This text typically contains colloquial business inquiries, such as asking about the price of crushed stone or freight costs in a certain location. The system parses the raw text using a pre-configured natural language understanding module, transforming it into a machine-processable structured expression. The business intent refers to the standardized category of the user's query behavior, such as a price quote query, freight cost query, or multi-mine price comparison; the structured slots are the key business parameters necessary to support the execution of this intent, such as mine identification, specifications, shipping location, receiving location, and tonnage. This step achieves an initial mapping from unstructured human language to a standardized machine semantic space, laying the foundation for subsequent precise tool invocation.

[0029] Step S200: Determine whether the structured slots meet the preset completeness conditions. The completeness conditions are a set of preset verification rules used to evaluate whether the currently extracted slots are sufficient to support an unambiguous business query. These conditions cover three levels: slot completeness, slot value clarity, and logical consistency between slots, and are key routing nodes in the entire query chain. At the completeness level, the system determines the corresponding mandatory slot set based on the business intent type; only when all mandatory slots are filled can the query pass. At the clarity level, the system calculates the confidence score of each slot; only when the confidence score of all mandatory slots is not lower than a preset threshold is the slot value considered sufficiently clear. At the logical consistency level, the system verifies whether the logical relationship between filled slots is reasonable, including spatial node conflict verification, business entity and attribute matching verification, and spatiotemporal validity verification. If a slot is missing or ambiguous, the system enters the clarification and completion process; if the slot is complete and clear, it directly enters the tool matching and execution process. This pre-verification mechanism prevents the system from blindly calling backend tools or making probabilistic guesses using large language models when parameters are incomplete, thus ensuring the certainty and controllability of subsequent operations.

[0030] In step S300, if the completeness condition is not met, the pre-registered master data read-only tool is invoked to obtain the corresponding candidate list. Based on the candidate list, the user's confirmation result is obtained, and the structured slots are updated according to the confirmation result until the completeness condition is met. Specifically, when the system determines that a slot is incomplete, it will not directly report an error or automatically fill in default values, but will proactively initiate a round of controlled interactive clarification. Based on the type of missing or ambiguous slot, the system automatically selects the corresponding master data read-only tool (such as a mine information query tool, specification dictionary query tool, etc.), queries a list of candidate business objects that meet the current context constraints, and presents this list to the user for selection. The result confirmed by the user is considered as high-confidence factual evidence and used to update the current structured slots. This process may be executed multiple times until all necessary slots are explicitly filled. In this way, the system transforms ambiguous references in natural language into precise business entity references, eliminating the root cause of model illusion and ensuring the absolute accuracy of query parameters.

[0031] In step S400, if the completeness condition is met, the system matches the target query tool from the pre-registered read-only tool set based on the business intent, and generates a tool call request based on the parameter template of the target query tool. Specifically, the system maintains a pre-registered read-only tool set, each tool corresponding to a specific business query capability and bound to a strict parameter template. Once the slots are complete, the system accurately matches a unique target query tool from this set based on the identified business intent. Subsequently, the system maps the values ​​in the structured slots one by one to the parameter template of the target query tool, generating a standardized tool call request. The parameter template defines the parameter name, type, required fields, and valid range. This template-driven generation method enforces constraints on the model's output format, preventing the generation of invalid parameters or unexpected SQL statements, thereby ensuring the security and stability of the backend interface at the architectural level.

[0032] Step S500: Based on the tool call request, obtain the current status information of the target business data snapshot corresponding to the target query tool, and determine whether the current status information meets the preset availability conditions. Specifically, before executing the actual data query, the system will first perform a pre-verification of the health status of the target business data snapshot. The target business data snapshot is a read-only view storing approved and managed business fact data, and its current status information reflects the timeliness and integrity of the data. The system reads this status information and makes a judgment based on the preset availability conditions. The availability conditions cover three levels: snapshot status validity, data timeliness, and data integrity. This judgment step constitutes a hard gate for query execution. At the snapshot status validity level, the system reads the snapshot status identifier, which can only be read when the status is active; refreshing, failed, or uninitialized states are unavailable. At the data timeliness level, the system reads the last refresh time of the snapshot, and only considers the data sufficiently fresh if the difference between the snapshot and the current time is within the preset validity period. At the data integrity level, the system verifies whether the data range covered by the snapshot is complete, confirming that the queried business object has a corresponding data entry in the snapshot and no refresh batch failure records. When all three conditions are met, the query is deemed available and allowed; if any condition is not met, the request is immediately blocked and a standardized error response is returned. Simultaneously, the large language model is restricted from using historical version data or generating guesses to replace actual business facts. This hard-gate mechanism fundamentally prevents intelligent queries from generating erroneous conclusions based on expired, corrupted, or updating data, addressing the technical flaw in existing technologies where models tend to fabricate answers when data is missing.

[0033] Step S600: If the availability condition is met, the system reads business fact data from the target business data snapshot and performs a query using the target query tool, outputting the query results; if the condition is not met, the query is aborted and a status error message is returned. Specifically, this step forms a binary path for query execution. In path one, when the snapshot status is available, the system securely reads the business fact data through the target query tool, and the large model service generates the final answer text based on this real data, ensuring the objectivity and authenticity of the answer content. In path two, when the snapshot status is unavailable, the system immediately aborts the query process and returns a clear status error message to the user, informing them that the data is temporarily unavailable. This hard rejection mechanism cuts off the possibility of the model using historical caching or contextual reasoning to "make up answers." Although it sacrifices response rate in some scenarios, it gains absolute rigor and credibility of the business decision data.

[0034] Example 2 like Figure 2As shown, based on Example 1, this example further refines the query request construction and parameter standardization mechanism, aiming to eliminate the illusion space of the model through a controlled intermediate layer and achieve a reliable transformation from vague user intent to precise machine instructions. As one implementation method, the confidence score of each structured slot is calculated, and structured slots with confidence scores below a preset threshold are marked as slots requiring clarification. Specifically, during the natural language understanding stage, the system evaluates the confidence of each extracted slot. This score is typically between 0 and 1, used to quantify the certainty of the slot value. When the slot value originates from a clear entity match in the user input, the confidence is usually high (e.g., greater than or equal to 0.9); while when the slot value originates from fuzzy matching, contextual reasoning, or partial keyword hits, the confidence is in a lower range (e.g., between 0.5 and 0.9); if it cannot be extracted, the confidence is 0. A preset threshold (e.g., 0.9) serves as the dividing line for the system to determine whether manual intervention is required. Only slots with values ​​above this threshold are considered as directly usable parameters, while slots with values ​​below this threshold are automatically marked as pending clarification. This avoids the system blindly executing subsequent queries when parameters are uncertain.

[0035] As one implementation method, the system invokes the master data read-only tool corresponding to the slot to be clarified to obtain a candidate list containing multiple candidate business objects. Specifically, for each slot marked as needing clarification, the system automatically routes the request to the corresponding master data read-only tool based on its semantic type. For example, if the user input contains the abbreviation or alias of a mining company, causing the system to identify multiple matching mining entities with confidence levels below a threshold, the system will invoke the mining information query tool, passing in the fuzzy keyword as a search condition. The candidate list returned by the tool is a structured dataset, where each record contains not only a unique business object identifier but also auxiliary distinguishing information such as name, alias, affiliated enterprise, and location. This candidate generation mechanism based on real master data ensures that the options provided to the user are all legitimate business entities existing in the system, rather than fictitious content generated out of thin air by the model, guaranteeing the authenticity of the data from the source.

[0036] As one implementation method, based on the confirmation results obtained from the candidate list, the candidate business object corresponding to the confirmation result is used as a high-confidence slot value and updated in the structured slots. Specifically, the system presents the candidate list to the user in the form of multiple-choice questions or grouped lists, waiting for the user's explicit confirmation. Once the user's selection feedback is received, the system immediately writes the unique identifier of the candidate business object as the slot value into the session context and forcibly updates its confidence to the highest value (e.g., 1.0), while recording that the source of the slot is the user's active confirmation. This process achieves closed-loop solidification of the slot status: only slots confirmed by the user can enter the subsequent tool invocation stage. If there are still other slots that do not meet the completeness conditions after the user's confirmation, the system will iteratively execute the above clarification process until all necessary slots reach a high-confidence state. This human-machine collaborative disambiguation mechanism effectively solves the common problem of ambiguous reference in natural language queries and ensures the absolute accuracy of query parameters.

[0037] After ensuring the completeness of the available slots, the system enters the tool matching and request generation phase. As one implementation method, based on business intent, a business intent classifier combined with regular expressions is used to match target query tools from a read-only tool set. Business intents include at least one of the following: price quote query, freight query, specification filtering, multi-mine price comparison, and landed cost calculation. Specifically, the system employs a dual matching strategy of "semantic classification + rule fallback." The intent classifier uses a lightweight semantic model to probabilistically predict user intents, handling colloquial and non-standard expressions. Regular expressions, as a supplement to deterministic rules, are used to accurately capture requests containing specific business keywords (such as "landed cost," "tax-inclusive price," etc.), preventing misjudgments in boundary cases. The pre-registered read-only tool set strictly limits the system's capability boundaries; each intent type is pre-bound to one or more compliant tool combinations. For example, the intent "landed cost calculation" necessarily involves a combined call to both the "current price quote query tool for mining products" and the "current freight quote query tool for shipping routes." This hard-coded mapping completely prevents the model from creating its own tools or splicing illegal SQL statements, ensuring that query behavior always takes place within a controlled business semantic space.

[0038] As one implementation method, structured slots are mapped to parameter templates of the target query tool. These structured slots include business entity dimensions, spatial node dimensions, and business indicator dimensions, with each parameter in the parameter template corresponding one-to-one with a structured slot. Specifically, each pre-registered target query tool defines a strict parameter template that describes all the input specifications required for tool execution. When generating a tool call request, the system does not directly pass the original slot values ​​to the tool. Instead, based on predefined mapping rules, it fills the slot values ​​for business entity dimensions (such as mine identifiers), spatial node dimensions (such as shipping location and receiving location), and business indicator dimensions (such as tonnage and tax rates) one by one into the corresponding fields of the parameter template. This one-to-one mapping mechanism enforces standardized data flow formats, ensuring that regardless of the diversity of the user's original expression, the request ultimately passed to the backend tool is always a standardized structure, eliminating the risk of call failure due to inconsistent parameter formats.

[0039] As one implementation method, the parameters in the parameter template undergo secondary validation for type, valid range, and required fields. Once the validation passes, a tool invocation request is generated. Specifically, after the parameters are filled in but before the request is sent, the system executes an independent validation gate at the business data abstraction access layer. Type validation ensures that the parameter values ​​conform to the expected data type (e.g., identifiers must be in valid UUID format); valid range validation ensures that the values ​​of enumerated parameters (e.g., tonnage gear) exist within a predefined dictionary range, and that numeric parameters are within a reasonable business range; required field validation ensures that all parameters marked as required have been assigned values. Only when all three types of validation pass will the system officially generate and send the tool invocation request; any validation failure will directly trigger a local error return without initiating an invalid request to the backend. This "clarification before verification" double-insurance mechanism constitutes the core defense point that distinguishes this invention from existing natural language to SQL solutions: the former eliminates ambiguity at the input end through a controlled candidate list and eliminates illegal construction at the output end through strict parameter template verification, thereby physically blocking the path of model illusion at two key stages and significantly improving the success rate of tool calls and the credibility of business queries.

[0040] Example 3 like Figure 3As shown, based on Embodiments 1 and 2, this embodiment further refines the data snapshot status verification and hard rejection mechanism, aiming to construct a complete query circuit breaker logic to physically block the possibility of large language models generating speculative results when data is missing or unavailable. As one implementation method, the view refresh status and last refresh time are extracted from the current status information; the view refresh status includes active status, refreshing status, failed status, and uninitialized status. Specifically, the target business data snapshot is not a static, unchanging storage table, but a dynamic view object with a lifecycle state. After receiving the tool call request, the system first reads the metadata record of the view object. The active status indicates that the view data is complete and has successfully completed the most recent atomic refresh, and is in a readable state; the refreshing status indicates that the background is performing batch data writing operations, at which time the data in the view may be in an intermediate state of alternation between old and new, lacking business consistency; the failed status indicates that the previous refresh task failed to complete successfully due to rule verification failure, database anomalies, etc., and the view data may remain in an earlier version or be in a corrupted state; the uninitialized status indicates that the view has not been created or has never successfully loaded data. These four enumeration values ​​cover the entire lifecycle of a data view, from creation and update to exceptions, providing a precise state machine basis for subsequent availability determination.

[0041] As one implementation method, if the view refresh status is active and the difference between the last refresh time and the current time is within a preset validity period, the current status information is determined to meet the availability conditions. If the view refresh status is in a refreshing, failed, or uninitialized state, or the difference between the last refresh time and the current time exceeds the preset validity period, the current status information is determined to not meet the availability conditions. Specifically, simply having an active view is insufficient to guarantee the business validity of the data, as data such as quotations and freight costs in the aggregate supply chain are highly time-sensitive. The system calculates the time difference between the current system time and the last refresh time recorded in the metadata, and compares it with a preset validity period threshold (e.g., 24 hours or a duration dynamically configured according to the business type) to quantify the "freshness" of the data. Only when the view is both in a stable active state and has completed a refresh within the time window will the system allow the query request. Conversely, if the status is inactive, or if it is active but the data has expired, the system determines that the availability conditions are not met. This dual verification mechanism of "status + timeliness" constitutes a hard gate in the intelligent query chain, ensuring that the data entering the query execution stage is necessarily processed and meets the current business timeliness requirements, effectively preventing the problem of distorted pricing caused by data refresh delays, task backlogs, or refresh failures.

[0042] When it is determined that the current status information does not meet the availability conditions, such as Figure 4As shown, the system enters the exception handling process. As one implementation, a status exception message is generated, containing standardized error codes, error descriptions, and suggested action information. The standardized error codes include at least one of the following: view expired, view refreshing, or view refresh failed. Specifically, the system does not return ambiguous natural language errors or null values ​​to the front-end or large model service; instead, it constructs a structured exception response object. This object contains machine-readable standardized error codes (such as VIEW_EXPIRED, VIEW_REFRESHING, VIEW_FAILED) for downstream components to perform precise logical branching; it also contains human-readable error descriptions (such as "The current quote view is refreshing, expected to complete in 2 minutes") and suggested action information (such as "Please try again later" or "Contact the administrator to check the refresh task") to guide user behavior. This structured design ensures that exception information is displayed in a user-friendly manner on the front-end interface, accurately recorded by the audit module, and used as explicit contextual input by the large model service, avoiding secondary misunderstandings caused by ambiguous error information.

[0043] As one implementation method, an anomaly status message is passed through to the front-end display, and a system-level hard rejection and prompt word constraints are used to jointly prevent the pre-configured large language model from generating speculative query results based on historical version data or contextual reasoning. Specifically, this is the core defense point that distinguishes this application from existing retrieval augmentation generation (RAG) schemes. In existing technologies, when relevant data cannot be retrieved, large models often tend to use their pre-trained knowledge or fragmented information in the context to "make things up in a seemingly reasonable but completely fictitious way," generating quotes or shipping costs that appear reasonable but are actually fabricated. To overcome this deficiency, this embodiment employs a dual blocking approach. The first layer is a system-level hard rejection: when the view status verification fails, the back-end service directly intercepts the request at the API layer and returns the aforementioned structured anomaly response, without providing the model with any historical version data or partial data fragments, physically cutting off the model's source of "fabricated material." The second layer is the constraint of prompt words: negative constraint instructions for such abnormal responses are pre-embedded in the system prompt words or tool call return specifications, explicitly informing the model that "when receiving specific error codes such as VIEW_EXPIRED, it is strictly forbidden to attempt inference, estimation, or use old data to answer; the error message must be truthfully relayed." Through the synergistic effect of this "physical supply cutoff" and "semantic prohibition," the system forces the model to remain silent or only convey official abnormal information when data is unavailable, thereby completely eliminating the space for model illusion and ensuring the absolute rigor and credibility of business decision data.

[0044] Example 4 Building upon Examples 1 to 3, this example further refines the generation method and rule governance mechanism for target business data snapshots. The aforementioned examples established rigid constraints on the query side, while the data writing governance link described in this example is the material basis for these constraints to take effect, ensuring that every piece of data entering the snapshot is a cleaned, verified, and compliant business fact. As one implementation method, business fact data that has been verified and approved by the rule governance engine is obtained; wherein, the rule governance engine verification includes mandatory field verification, enumeration range verification, numerical range verification, semantic uniqueness fingerprint verification, and cross-field dependency verification. Specifically, in the aggregate supply chain scenario, the raw data submitted by business personnel often has problems such as non-standard format, logical conflicts, or duplicate entries. Directly writing it into the database would pollute the query results. Therefore, the system sets up a rule governance engine as a quality gate before the data is written to the database. Required field validation ensures that key business elements (such as mine identification and price) are not empty; enumeration range validation verifies whether field values ​​belong to a predefined valid set, for example, tonnage must be a standard range such as "0-500 tons" or "500-1000 tons", and tax / price must be "tax included" or "tax excluded"; numerical range validation is used to intercept abnormal data, such as preventing negative prices or freight costs from exceeding a reasonable range. These basic validations constitute the first line of defense for data quality, ensuring the integrity and basic legality of the data.

[0045] Building upon the aforementioned basic verification, this application introduces a more targeted semantic-level verification mechanism. As one implementation method, semantic uniqueness fingerprint verification includes: concatenating the mine identifier, specification identifier, and price version from the business fact data, calculating a hash value as the semantic fingerprint, and querying whether the same semantic fingerprint already exists. If it does, it is determined to be a duplicate submission, and the verification fails. Specifically, in traditional ledger or wide-table entry modes, the same quotation transaction is often entered multiple times due to human error, resulting in multiple contradictory "current prices" during queries. To address this pain point, this embodiment defines a composite primary key composed of "mine identifier + specification identifier + price version" as the semantic fingerprint of the business fact. The combination of these three dimensions uniquely identifies a valid quotation record in the aggregate supply chain. The system calculates a hash value (e.g., SHA-256) on this concatenated string to generate a fixed-length fingerprint digest, and queries the index table to see if the same fingerprint already exists before writing it. This deduplication mechanism, which is based on semantics rather than simply database auto-incrementing IDs, can accurately identify duplicate data from the perspective of business meaning. Regardless of the order of entry or the source channel, as long as the business substance is the same, it will be blocked, thereby fundamentally ensuring the uniqueness and authority of the facts in the target business data snapshot.

[0046] As one implementation method, cross-field dependency validation includes checking the logical consistency between different fields in the business fact data. If conflicts exist, the validation fails. Specifically, there are complex business logic relationships within the aggregate supply chain data, and the validity of a single field does not represent the rationality of the entire record. For example, when the "tax price caliber" field value is "tax-inclusive price," the "tax rate" field must be non-empty and a valid value; when "shipping location" and "receiving location" are the same, it is usually invalid data for freight query scenarios; or when "product specification" is a specific model, its corresponding "quality indicators" must meet the lower limit of the national standard for that model. The rule governance engine automatically validates the logical relationships between fields through pre-configured dependency rule expressions. This validation mechanism compensates for the blind spots of single-field validation, ensuring that the data written to the snapshot is not only formally correct but also logically consistent, avoiding intelligent query inference errors caused by internal data contradictions.

[0047] To improve validation efficiency and provide accurate error correction feedback, the rule governance engine employs a short-circuit execution strategy as one implementation method: if any rule validation fails, the execution of subsequent rules is immediately terminated and writing is blocked. A failure reason is generated and stored in a structured format, containing the rule key, rule description, failure field, and expected value. Specifically, unlike the traditional batch validation model that returns all errors, the short-circuit execution strategy immediately triggers a circuit breaker upon detecting the first violation. This design avoids consuming computational resources to perform subsequent complex validations when the data is known to be invalid, thus improving system throughput. Furthermore, it encapsulates the failure reason as a structured object containing the rule key, a human-readable rule description, the specific failure field, and the expected value, rather than a simple text error message. This structured storage allows the front-end to accurately locate and highlight problematic fields, while also facilitating automated data quality statistical analysis by the auditing module. More importantly, it ensures that only "clean" data that has completely passed all validation rules can proceed to the next stage, eliminating the possibility of faulty data being accidentally entered into the database.

[0048] After the data passes all verifications and completes the approval process, the system performs the final snapshot refresh operation. As one implementation method, a unique refresh batch identifier is generated based on the business fact data. The business fact data and refresh batch identifier are refreshed to the target business data snapshot using an atomic batch approach, and the current status information is updated after the refresh is complete. Specifically, the refresh batch identifier (refresh_batch_id) is the key link between data writing and query reading. It assigns a globally unique version number to each data change, supporting data traceability and version rollback when necessary. The atomic batch refresh mechanism requires that all data rows involved in this change either be successfully written to the snapshot or be completely rolled back in the event of any exception, and absolutely prohibits any intermediate state of partial updates. This ensures that the target business data snapshot always presents a complete and consistent business factual aspect. Only after the refresh operation is completely completed will the system update the view status to "active" and record the last refresh time. This timing arrangement forms a tight logical closed loop with the snapshot status verification mechanism in Example 3: the "available status" read by the query side must be the result after the data side has completed atomic writing and the governance engine has confirmed its accuracy.

[0049] Example 5 like Figure 5 As shown, this embodiment provides an intelligent query system 700 for aggregate supply chain based on business fact constraints. This system 700 implements the rigid query link in the aforementioned method embodiment through a modular architecture design, aiming to cover the technical solution of intelligent query from the product form level. The system includes a natural language understanding module 701, a slot completeness judgment module 702, a candidate clarification module 703, a tool matching and request generation module 704, a snapshot status verification module 705, and a query execution and output module 706. Each module can be implemented as a software component, hardware circuit, or a combination of both. It can be deployed on a single server or distributed across multiple collaborative computing nodes; this application does not limit this.

[0050] The Natural Language Understanding module 701 is used to acquire user-input natural language query requests, identify business intent, and extract corresponding structured slots. Specifically, this module serves as the entry point for the query chain during system runtime, integrating a semantic parsing engine and an intent classifier. In actual deployment, this module's functionality can be achieved by calling a remote large language model service, or by using a combination of a locally deployed lightweight NLP model and a rule engine. The output of this module is connected to the input of the slot completeness judgment module, transforming unstructured user text into structured data packets containing intent tags and slot key-value pairs, providing a standardized semantic foundation for subsequent processing.

[0051] The slot completeness judgment module 702 is used to determine whether structured slots meet preset completeness conditions. Specifically, this module acts as an intelligent traffic divider for the query process. It receives structured data from the natural language understanding module and verifies the existence and confidence threshold of required slots according to preset business rules. This module has two output branches: the first branch connects to the candidate clarification module, which triggers the clarification process when slots are missing or ambiguous; the second branch connects to the tool matching and request generation module, which directly advances the query when slots are complete. This hard-wired traffic division logic ensures that the system will not enter the backend query stage when parameters are incomplete, thus architecturally preventing the generation of invalid requests.

[0052] The candidate clarification module 703 is used to retrieve the corresponding candidate list by calling a pre-registered master data read-only tool if the structured slot does not meet the completeness condition. Based on the candidate list, it obtains the user's confirmation result and updates the structured slot according to the confirmation result until the completeness condition is met. Specifically, this module is the core unit for implementing human-machine collaborative disambiguation. When it receives the first branch signal from the slot completeness judgment module, this module obtains the actual set of business object candidates through a pre-registered master data read-only tool (such as a mine information query tool or a specification dictionary query tool). Subsequently, this module displays the candidate options to the user through the front-end interface and receives selection feedback. It writes the confirmed entity identifier back to the slot mapping table in the session context and re-sends the updated complete slot data to the slot completeness judgment module or directly to the tool matching and request generation module. This closed-loop mechanism ensures that every slot value entering the query stage is a high-confidence fact confirmed by the user.

[0053] The tool matching and request generation module 704 is used to match the target query tool from a pre-registered read-only tool set based on the business intent if the structured slots meet the completeness condition, and generate a tool call request based on the parameter template of the target query tool. Specifically, this module maintains a mapping table between intent types and tool combinations, as well as a strict parameter template for each tool. When complete slot data is received, this module first retrieves the target tool based on the intent tag, then fills the slot values ​​into the parameter template according to the one-to-one mapping rules, and performs secondary validation of type, range, and required fields. Only requests that pass the validation are encapsulated into standardized API call instructions and sent to the backend service. This template-driven request generation method strictly limits the query capabilities exposed by the system to a predefined tool set, effectively preventing illegal SQL injection or unexpected parameter construction.

[0054] The snapshot status verification module 705 is used to obtain the current status information of the target business data snapshot corresponding to the target query tool based on the tool call request, and to determine whether the current status information meets the preset availability conditions. Specifically, this module constitutes a security gate before query execution. It maintains communication with the backend service and database, and reads the refresh status and timestamp in the view metadata in real time. The module internally implements a dual judgment logic of "status + timeliness". Only when the view is active and the refresh time is within the validity period will a signal allowing the query be output; otherwise, a blocking signal will be output. This verification mechanism ensures that the data base on which intelligent queries rely is always fresh and consistent, avoiding business decision risks caused by data synchronization delays or refresh failures.

[0055] The query execution and output module 706 is used to read business fact data from the target business data snapshot if the current status information meets the availability conditions, and then perform a query through the target query tool and output the query results; if the current status information does not meet the availability conditions, the query is terminated and a status exception prompt is returned. Specifically, this module is the end point of the query chain and is responsible for performing binary path operations based on the output signal of the snapshot status verification module. Under the available path, this module drives the target query tool to extract fact data from the current view and generate a natural language answer in combination with the large language model service. At the same time, sensitive information is removed through the output filter and returned to the front end as a streaming event; under the unavailable path, this module directly intercepts the query request, generates a structured exception response containing standardized error codes and suggested operations, and prohibits the model from performing any form of speculative generation through a system-level hard rejection mechanism. Through the collaborative work of the above modules, this embodiment constructs an end-to-end controlled, fact-strongly constrained, and self-circuit-breaking intelligent query system, fully replicating the technical effects of the method embodiment.

[0056] Example 6 Building upon Examples 1 to 5, this example further refines the end-to-end security control and transparent output mechanism, aiming to construct an end-to-end security and experience closed loop from request entry to response exit, ensuring the security and observability of intelligent queries in an enterprise-level multi-tenant environment. As one implementation method, the API client's key is used to perform HMAC signing on the tool call request. The backend service verifies the validity of the HMAC signature upon receiving the tool call request. The HMAC signature includes the request method, path, timestamp, parameters, and user identifier. Specifically, when the business data abstraction access layer prepares to initiate a tool call to the backend service, it does not directly send a plaintext request. Instead, it uses a pre-allocated APIClient key to perform Hash Message Authentication Code (HMAC) calculations on the key elements of the request. The signature content covers the HTTP request method, URL path, millisecond-level timestamp, serialized parameter body, and current user identifier. This combination ensures the uniqueness and timeliness of the signature. Upon receiving the request, the backend service first verifies whether the timestamp is within the allowed window period to prevent replay attacks, and then recalculates the signature using the same key and compares it with the signature value in the request header. Only when both are completely identical is the request considered legitimate. This mechanism physically blocks the possibility of requests being tampered with or forged by a man-in-the-middle at the transport layer, ensuring the integrity and authenticity of tool invocation instructions.

[0057] As one implementation method, a user identifier field and a resource scope identifier field are injected into the request header of the tool invocation request. The backend service performs user isolation and permission verification based on the user identifier field and the resource scope identifier field. Specifically, in addition to identity authentication, the system also implements fine-grained tenant-level data isolation. The user identifier field (such as X-Tenant-ID) clearly defines the tenant boundary to which the request belongs. The backend service uses this to forcibly filter data from non-tenant users to prevent cross-tenant data leakage. The resource scope identifier field (such as X-Resource-Scope) defines the granularity of the operation permission for this invocation. For example, "read:quote" only allows reading quotation data, and "read:freight" only allows reading freight data. Even different users or different tools within the same tenant must hold the corresponding Scope token to access specific resources. This dual verification mechanism of "identity + scope" enables the intelligent query system to securely serve multiple isolated supply chain enterprises on a shared infrastructure, completely eliminating the risk of unauthorized access caused by prompt word injection or model illusion, and providing a solid security foundation for SaaS deployment.

[0058] After ensuring secure input, the system also implements strict control and transparency measures for the output results. As one implementation method, multi-layered output filtering is applied to query results. This multi-layered filtering includes: removing internal database primary keys, user identifiers, API signatures, trace codes, underlying table names, and raw SQL fragments; removing debug stacks and internal error codes; and formatting numerical data according to preset business rules. Specifically, the raw answers generated by large models or the raw data returned by tools often contain a large amount of internal system information that should not be exposed to end users. Before pushing the results to the front end, the system performs an output filter for cleaning. The first layer of cleaning targets sensitive metadata, forcibly stripping database auto-incrementing IDs, UUIDs, tenant IDs, API signatures, and internal trace codes to prevent attackers from deducing system architecture or forging credentials through response content; it also removes underlying table names and raw SQL fragments to avoid injection risks caused by database structure leaks. The second layer of cleaning targets debug information, removing code stack traces and internal error codes, retaining only user-understandable business-level error descriptions to prevent the leakage of technical details. The third layer of processing targets the presentation of business data. It formats the raw numerical data (such as price and tonnage) according to common standards in the aggregate industry, such as uniformly retaining two decimal places, adding thousands separators, or adding unit suffixes to improve the reading experience. This multi-layered filtering mechanism ensures that the content ultimately presented to users is both clean and secure, and conforms to business practices, achieving a balance between security and usability.

[0059] As one implementation method, the filtered query results and execution process status information are output in stages using a streaming server-sent event protocol. The query results are incremental responses, and the execution process status information includes intent recognition status, slot filling progress, tool invocation status, view verification status, and audit summary. Specifically, to overcome the distrust caused by the "black box waiting" of traditional question-answering systems, this embodiment uses the Server Sending Events (SSE) protocol to white-box the query process. The system no longer waits for all steps to complete before returning the results all at once, but instead pushes an event stream in stages according to the execution sequence. For example, an intent_start event is pushed when intent recognition is complete; slot_filling or clarification events are pushed during slot extraction or clarification; tool_call_start and tool_call_done events are pushed before and after tool invocation, respectively; a view_check event is pushed when view verification passes; finally, incremental responses are streamed using text_delta events, and the system concludes with an audit summary including token consumption, time consumption statistics, and other audit information for this query. This phased output design has dual technical benefits: on the one hand, it allows users to perceive the AI's thought process and execution progress in real time, significantly reducing anxiety during long-chain queries and enhancing trust in human-computer interaction; on the other hand, it provides high-precision structured trajectory data for the audit log module, enabling the entire process of intent recognition, tool selection, parameter generation, data verification, and result generation for each query to be accurately replayed and traced, meeting the stringent requirements of enterprise-level applications for compliance and interpretability.

[0060] Example 7 To more clearly illustrate the synergistic effects and technical capabilities among the various embodiments of this application, a detailed explanation is provided below using a specific integrated application scenario of multi-turn dialogue query and anomaly handling in an aggregate supply chain. In this application scenario, the system integrates the features of intent recognition, slot clarification, tool constraints, snapshot verification, security control, and transparent output from the aforementioned embodiments into a coherent business loop to verify the reliability and defensiveness of the technical solution in a real and complex environment.

[0061] In this scenario, suppose a business user inputs a natural language query request through the front end: "Query the landed cost of Conch Cement gravel in XX City." This request, seemingly simple, actually implies multiple business constraints and potential data risks. The system's processing flow for this request is as follows.

[0062] Step S801: Obtain the user's input natural language query request, identify the business intent, and extract the corresponding structured slots. Specifically, after receiving the text, the system first performs security filtering and input purification to confirm there is no risk of SQL injection or malicious commands. Subsequently, the intent classifier, combined with regular expressions, identifies the request as a "CIF cost calculation" intent. Simultaneously, the slot extraction module parses three initial slots from the text: "Consignment Location = XX City," "Mine = Conch," and "Specification = Crushed Stone." However, according to the parameter template requirements of the "CIF cost calculation" intent, the query must also include two key dimensions: "Shipping Location" and "Tonnage," which are not explicitly provided in the current request. At this point, the system determines that the structured slots do not meet the preset completeness conditions and automatically enters the clarification process instead of blindly guessing.

[0063] Step S802: The pre-registered master data read-only tool is invoked to obtain the corresponding candidate list. Based on the candidate list, the user's confirmation result is obtained, and the structured slots are updated according to the confirmation result. Specifically, for the missing "shipping location" slot, the candidate clarification module invokes the "shipping location list query tool" and, combined with the already identified "mine = Conch" as a filter condition, retrieves a list of all ports or wharves (e.g., Port A, Port B, etc.) under the mining company that have the capacity to ship crushed stone. At the same time, for the missing "tonnage" slot, the "tonnage dictionary query tool" is invoked to obtain the list of currently valid freight pricing tiers. The system pushes these two sets of candidate options to the front end in the form of structured cards to guide the user to make a selection. After the user selects "Port A" and "500-1000 tons" on the interface, the system updates these two high-confidence values ​​to the slot mapping table in the session context. This process embodies the core value of the "controlled clarification" of this application: even when faced with ambiguous user instructions, the system can converge the dialogue to the legitimate business space through master data constraints, avoiding "illusionary" completion of the model due to lack of context.

[0064] Step S803 involves matching the target query tool from the pre-registered read-only tool set based on the business intent, and generating a tool call request based on the parameter template of the target query tool. Specifically, once all necessary slots are filled and the confidence level meets the standard, the tool matching and request generation module automatically matches the combined call sequence of the "Cost and Freight Forwarding Tool" and the "Current Price Quotation Query Tool for Mining Products" based on the intent of "Cost and Freight Forwarding Tool for Shipping Routes". The system strictly maps slot values ​​such as "Mining ID", "Specification ID", "Shipping Location ID", "Consignee Location ID", and "Tonnage Range" to the parameter templates of these two tools and performs secondary validation of type and range. For example, it checks whether "Tonnage Range" is an enumerated valid value and whether "Mining ID" is in valid UUID format. Only parameters that pass the validation are encapsulated into a standardized API request body, thereby eliminating the risk of illegal parameter injection at the source.

[0065] Step S804 involves using the API client's key to perform an HMAC signature on the tool call request and injecting the user identifier and resource scope identifier fields into the request header. Specifically, before the tool call request is sent, the business data abstraction access layer uses the pre-allocated API Client key to perform an HMAC operation on the request method, path, timestamp, parameter body, and user identifier to generate a signature. The signature value, X-Tenant-ID (tenant identifier), and X-Resource-Scope (e.g., read:quote, read:freight) are then injected into the HTTP request header. Upon receiving the request, the backend service first verifies the integrity and timeliness of the signature, and then performs permission verification based on the tenant identifier and resource scope. This step ensures that even in highly automated scenarios like intelligent queries, every data access is still protected by a strict enterprise-level security boundary, preventing cross-tenant data leakage or unauthorized queries.

[0066] Step S805: Obtain the current status information of the target business data snapshot corresponding to the target query tool, and determine whether the current status information meets the preset availability conditions. Specifically, before performing actual data reading, the snapshot status verification module queries the metadata of the "Current Price View of Mining Products" and the "Current Freight View of Shipping Routes". In the first attempt of this scenario, it is assumed that the backend is performing a daily routine price data refresh, and the view metadata shows view_status as "refreshing". According to the preset availability judgment rules, the system immediately determines that the current status information does not meet the availability conditions. This design is the key defense point that distinguishes this application from existing intelligent question answering systems: it acknowledges that there is a time window for data synchronization and chooses to actively circuit break the query within this window period, rather than returning potentially inconsistent intermediate state data.

[0067] In step S806, if the availability conditions are not met, the query is aborted and a status error message is returned. Specifically, the query execution and output module intercepts the original tool call request and generates a structured error response containing the standardized error code "VIEW_REFRESHING," the error description "Current price data is being updated and is expected to be completed in 2 minutes," and the suggested operation "Please try again later." More importantly, this response is returned directly to the system through a system-level hard rejection mechanism, and the system prompt message enforces that the large language model service must not generate any numerical answers based on historical cache or contextual reasoning. Therefore, what the user sees on the front end is a clear system notification, rather than a "predicted price" fabricated by the model. Although this approach temporarily interrupts the service, it fundamentally ensures the absolute rigor of business decision data and avoids the risk of trade disputes caused by data version inconsistencies.

[0068] In step S807, if the availability condition is met, business fact data is read from the target business data snapshot and queried using the target query tool. The query results are then filtered through multiple layers and output in stages via streaming server events. Specifically, assuming the user receives a prompt, waits briefly, and re-initiates the query, the view status has changed to "active" and the refresh time is within the validity period. The system successfully approves the request, reads the accurate ex-factory price and freight data from the current view, and calculates the total landed cost using the large language model service. In the output stage, the output filter first removes database primary keys, API signatures, internal tracking codes, and raw SQL fragments from the results, and formats the price values ​​with thousands separators and unit annotations. Subsequently, the system transparently pushes the execution process to the front end via the SSE protocol: first, it sends an intent_done event to confirm the intent; then, it sends a tool_call_done event to show that the data acquisition was successful; next, it streams a text message with the text_delta event stating, "According to the latest data, the landed cost of conch gravel (500-1000 tons) shipped from Port A to City XX is..."; finally, it sends an audit event with a summary of the query time and token consumption. This phased, transparent output not only allows users to perceive the system's thought process and data freshness in real time, but also provides complete structured evidence for subsequent auditing and tracing.

[0069] The complete demonstrations of the above two scenarios demonstrate that the technical solution of this application is not a simple aggregation of single functions, but rather an organically coordinated defense system. The slot clarification mechanism resolves input ambiguity issues, tool constraints and parameter validation address execution legitimacy issues, snapshot status validation and hard rejection mechanisms address data timeliness and authenticity issues, while secure signatures and output filtering consistently ensure system security and compliance. These features work together to enable the intelligent query system to be truly implemented in the aggregate supply chain, a vertical field with extremely high data accuracy requirements, achieving a fundamental leap from "probabilistic generation" to "factual querying."

[0070] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art, within the technical scope disclosed in this application, based on the business fact constraint mechanism, rigid query link construction concept, and data governance closed-loop principle disclosed in this application, can easily conceive of corresponding changes or substitutions, such as adjusting the slot completeness verification strategy, expanding the view state enumeration type, changing the secure signature algorithm, or optimizing the output filtering rules, etc., as long as they do not depart from the core concept of this application and can achieve the same or equivalent technical effects, they should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for intelligent querying aggregate supply chains based on business fact constraints, characterized in that, include: Obtain the user's input natural language query request, identify the business intent, and extract the corresponding structured slots; Determine whether the structured slots meet the preset completeness conditions; If the condition is not met, the pre-registered master data read-only tool is invoked to obtain the corresponding candidate list, the user feedback confirmation result is obtained based on the candidate list, and the structured slot is updated according to the confirmation result until the completeness condition is met. If the conditions are met, the target query tool is matched from the pre-registered read-only tool set based on the business intent, and a tool call request is generated based on the parameter template of the target query tool. Based on the tool call request, obtain the current status information of the target business data snapshot corresponding to the target query tool, and determine whether the current status information meets the preset availability conditions; If the conditions are met, business fact data is read from the target business data snapshot and queried using the target query tool, and the query results are output; if the conditions are not met, the query is stopped and a status error message is returned.

2. The intelligent query method for aggregate supply chain based on business fact constraints according to claim 1, characterized in that, The step of obtaining the user's confirmation result based on the candidate list and updating the structured slot according to the confirmation result includes: Calculate the confidence score for each of the structured slots, and mark the structured slots with confidence scores lower than a preset threshold as slots to be clarified; Invoke the master data read-only tool corresponding to the slot to be clarified to obtain the candidate list containing multiple candidate business objects; Based on the candidate list, the user feedback confirmation result is obtained, and the candidate business object corresponding to the confirmation result is used as the high confidence slot value and updated to the structured slot.

3. The intelligent query method for aggregate supply chain based on business fact constraints according to claim 1, characterized in that, The step of matching a target query tool from a pre-registered set of read-only tools based on the business intent, and generating a tool invocation request based on the parameter template of the target query tool, includes: Based on the business intent, the target query tool is matched from the read-only tool set using an intent classifier combined with regular expressions; wherein, the business intent includes at least one of price quote query, freight query, specification filtering, multi-mine price comparison, and landed cost calculation; The structured slots are mapped to the parameter template of the target query tool; wherein, the structured slots include business entity dimensions, spatial node dimensions, and business indicator dimensions, and the parameters in the parameter template correspond one-to-one with the structured slots; The parameters in the parameter template are subjected to secondary validation for type, valid range and required fields. After the validation is successful, the tool call request is generated.

4. The intelligent query method for aggregate supply chain based on business fact constraints according to claim 1, characterized in that, The step of determining whether the current status information meets the preset availability conditions includes: Extract the view refresh status and last refresh time from the current status information; wherein, the view refresh status includes active status, refreshing status, failed status, and uninitialized status; If the view refresh status is the active status, and the difference between the last refresh time and the current time is within a preset validity period, then the current status information is determined to meet the availability condition. If the view refresh status is in the refresh process, failed, or uninitialized state, or if the difference between the last refresh time and the current time exceeds the preset validity period, then the current status information is determined not to meet the availability condition.

5. The intelligent query method for aggregate supply chain based on business fact constraints according to claim 4, characterized in that, The process of suspending the query and returning an error status message includes: Generate a status error message containing a standardized error code, error description, and suggested operation information; wherein the standardized error code includes at least one of view expiration, view refresh in progress, or view refresh failure; The abnormal status message is passed through to the front end for display, and the system-level hard rejection and prompt word constraints jointly prohibit the pre-configured large language model from generating speculative query results based on historical version data or contextual reasoning.

6. The intelligent query method for aggregate supply chain based on business fact constraints according to claim 1, characterized in that, The methods for generating the target business data snapshot include: Obtain business fact data that has been verified and approved by the rule governance engine; wherein, the rule governance engine verification includes required field verification, enumeration range verification, numerical range verification, semantic uniqueness fingerprint verification, and cross-field dependency verification; A unique refresh batch identifier is generated based on the aforementioned business fact data; The business fact data and the refresh batch identifier are refreshed to the target business data snapshot using an atomic batch method, and the current status information is updated after the refresh is completed.

7. The intelligent query method for aggregate supply chain based on business fact constraints according to claim 6, characterized in that, The semantic uniqueness fingerprint verification includes: concatenating the mine identifier, specification identifier and price version in the business fact data and calculating the hash value as the semantic fingerprint; querying whether the same semantic fingerprint already exists; if it exists, it is determined to be a duplicate submission and the verification fails. The cross-field dependency validation includes: checking the logical consistency between different fields in the business fact data; if there is a conflict, the validation fails. The rule governance engine adopts a short-circuit execution strategy: if any rule fails the verification, the execution of subsequent rules is immediately terminated and the writing is blocked. The failure reason is generated and stored in a structured manner. The failure reason includes the rule key, rule description, failure field and expected value.

8. The intelligent query method for aggregate supply chain based on business fact constraints according to claim 1, characterized in that, Following the parameter template generation tool call request based on the target query tool, the following is also included: The API client's key is used to perform an HMAC signature on the tool call request. The backend service verifies the validity of the HMAC signature after receiving the tool call request. The HMAC signature includes the request method, path, timestamp, parameters, and user identifier. The user identifier field and the resource scope identifier field are injected into the request header of the tool call request. The backend service performs user isolation and permission verification based on the user identifier field and the resource scope identifier field.

9. The intelligent query method for aggregate supply chain based on business fact constraints according to claim 8, characterized in that, The process of querying using the target query tool and outputting the query results includes: The query results are subjected to multi-level output filtering; wherein, the multi-level output filtering includes: removing the database internal primary key, the user identifier, API signature, trace code, underlying table name and original SQL fragment; removing the debug stack and internal error code; and formatting numerical data according to preset business rules; The filtered query results and execution process status information are output in stages by sending events via a streaming server; wherein, the query results are incremental response text, and the execution process status information includes intent recognition status, slot filling progress, tool invocation status, view verification status, and audit summary.

10. A business fact-based intelligent query system for aggregate supply chain, used to implement the business fact-based intelligent query method for aggregate supply chain as described in any one of claims 1 to 9, characterized in that, include: The Natural Language Understanding module is used to acquire natural language query requests input by users, identify business intent, and extract corresponding structured slots; The slot completeness judgment module is used to determine whether the structured slot meets the preset completeness conditions. The candidate clarification module is used to, if the structured slot does not meet the completeness condition, call the pre-registered master data read-only tool to obtain the corresponding candidate list, obtain the user feedback confirmation result based on the candidate list, and update the structured slot according to the confirmation result until the completeness condition is met. The tool matching and request generation module is used to match a target query tool from the pre-registered read-only tool set based on the business intent if the structured slot meets the completeness condition, and generate a tool call request based on the parameter template of the target query tool. The snapshot status verification module is used to obtain the current status information of the target business data snapshot corresponding to the target query tool based on the tool call request, and to determine whether the current status information meets the preset availability conditions. The query execution and output module is used to read business fact data from the target business data snapshot if the current status information meets the availability conditions, and to perform a query through the target query tool and output the query results. If the current status information does not meet the availability conditions, the query is terminated and a status error message is returned.

Images