A method and system for generating an execution plan of a database semantic query

Abstract

The application provides a database semantic query execution plan generation method and system, the execution plan generation method comprises the following steps: receiving an SQL query statement; identifying a semantic expression in the SQL query statement, generating semantic operator metadata for the semantic expression; splitting the normal relational expression and the semantic expression in the SQL query statement into normal relational operators and logical semantic operators; when the logical semantic operator depends on multi-modal large field data, performing on-demand reading or decoding on the multi-modal data; compiling the database output type constraint or the user-specified structure mode into a model structured output constraint; merging multiple rows of input within the same data block into a batch model request; performing structured verification on the result returned by the model, and outputting an SQL query result; and performing corresponding degradation processing according to the degradation strategy in the semantic operator metadata. Thus, the explainability, governability and structured result availability of semantic calculation in the database query plan can be improved.

Description

Technical Field

[0001] This invention relates to the field of data processing, and in particular to a method and system for generating execution plans for database semantic queries. Background Technology

[0002] The integration of databases and artificial intelligence models has become a significant trend in the field of data processing. Mainstream commercial databases and lakestore platforms have successively provided the ability to call AI models within SQL, allowing users to perform semantic computation tasks such as classification, extraction, and summarization on multimodal data including text, images, and videos using custom functions or built-in semantic functions. This capability enables developers to directly complete processing tasks that previously required independent AI service chains within a familiar SQL environment, lowering the barrier to application development.

[0003] However, existing solutions still have significant shortcomings when incorporating semantic computation into the database query system. First, semantic functions are often treated as ordinary user-defined functions by the optimizer, and the engine cannot perceive their high latency, high cost, and external I / O characteristics, making dedicated scheduling optimization impossible. Second, the mixed execution of ordinary predicates and semantic predicates leads to a large number of data rows that could be filtered out at the relational level still triggering expensive model calls, resulting in wasted resources. Third, multimodal data (such as large binary fields like images, videos, and audio) are fully read and decoded during the query scanning phase; even if these rows are subsequently filtered out by ordinary conditions, decoding and transmission overhead has already been incurred. Fourth, the structured results output by the model lack database-level type constraint verification and repair mechanisms; the output JSON or field values ​​may be inconsistent with the target column definitions, affecting downstream data quality. Fifth, multiple semantic operations are often split into independent model calls; even if they operate on the same batch of data and the model configuration is compatible, they cannot be merged for execution, leading to duplicate token consumption and network overhead. Sixth, semantic computation is hidden inside ordinary function calls, and interpretable tools for query plans cannot display key indicators such as the number of model calls, failures, and resource consumption, resulting in a lack of visibility for operation and maintenance.

[0004] Therefore, a new method and system for generating execution plans for database semantic queries is needed to reduce unnecessary model calls and multimodal large field reads. Summary of the Invention

[0005] To overcome the above-mentioned technical defects, the present invention aims to provide a method and system for generating execution plans for database semantic queries, thereby improving the interpretability, manageability, and usability of structured results of semantic computation in database query plans.

[0006] This invention discloses a method for generating an execution plan for a database semantic query, which is executed by a database query engine, and includes the following steps: It accepts SQL query statements that contain semantic functions or semantic operators; Identify semantic expressions in SQL query statements and generate semantic operator metadata for semantic expressions. The semantic operator metadata describes the type, input and output specifications, model call configuration, and execution strategy of the semantic operator. The SQL query statement is split into ordinary relational expressions and semantic expressions into ordinary relational operators and logical semantic operators, so that ordinary predicate filtering, sampling, window slicing and limiting the number of returns are performed before the logical semantic operators; When logical semantic operators depend on multimodal large field data, after the ordinary relational operators have been executed, the multimodal data corresponding to the data rows that survive the filtering is read or decoded on demand. Compile database output type constraints or user-specified structural patterns into model structured output constraints; During the physical execution phase, multiple lines of input within the same data block are merged into a single batch model request based on the semantic operator grouping key, and the returned results are split back into the corresponding original data lines based on the line identifier. Perform structured validation on the results returned by the model and output the SQL query results; When the capabilities of the model service provider do not meet the requirements of the semantic operator metadata, the corresponding degradation processing is performed according to the degradation strategy in the semantic operator metadata.

[0007] Preferably, the multimodal large field data includes at least one of binary large objects, video frames, audio clips, and document pages.

[0008] Preferably, for video frame input, the system locates the target frame according to the hierarchical index structure of the video stream, decodes only the frames required by the semantic operators, and generates a binary large object array while maintaining the SQL array order.

[0009] Preferably, the database output type constraint is determined by at least one of the type declaration, null value constraint, enumeration constraint, and check constraint in the database column definition.

[0010] Preferably, when the model returns a result that fails to be validated, the system performs a retry repair or abnormal row record operation according to the error handling strategy.

[0011] Preferably, the semantic operator grouping key is determined by the model service provider identifier, the model identifier, the prompt word template fingerprint, and the output mode fingerprint, and multiple lines of input under the same grouping key are merged into one model call.

[0012] Preferably, when there are multiple compatible semantic operations on the same input data, the system merges the multiple semantic operations into a composite output pattern, returns multiple result fields simultaneously through a single model call, and splits the multiple result fields into corresponding SQL output columns or predicate results on the database side.

[0013] Preferably, the degradation processing is based on the type of capability that the model service provider does not support, and adopts either line-by-line calling, plain text output followed by verification, or rejection and return of error message.

[0014] Preferably, it also includes: displaying execution statistics of semantic operators in the interpretable output of the query execution plan, the execution statistics covering the number of model calls, the number of retries, the number of verification failures, and the amount of multimodal data read.

[0015] This invention also discloses a database semantic query execution plan generation system, comprising: The semantic expression recognition module is used to receive SQL query statements containing semantic functions or semantic operators and recognize the semantic expressions within them. The semantic operator metadata module is used to generate semantic operator metadata for semantic expressions. The semantic operator metadata describes the type, input and output specifications, model invocation configuration, and execution strategy of the semantic operator. The rewrite module is used to split ordinary relational expressions and semantic expressions in SQL query statements into ordinary relational operators and logical semantic operators, so that ordinary predicate filtering, sampling, window slicing and limiting the number of returns are executed before the logical semantic operators; The multimodal delayed read module is used to perform on-demand reading or decoding only on the multimodal data corresponding to the data rows that survive the filtering after the ordinary relational operator has been executed, when the logical semantic operator depends on multimodal large field data. The schema compilation and verification module is used to compile database output type constraints or user-specified structural schemas into model structured output constraints, and to perform structured verification on the results returned by the model. The data block batch processing module is used during the physical execution phase to merge multiple lines of input within the same data block into a single batch model request based on the semantic operator grouping key, and to split the returned results back into the corresponding original data lines based on the line identifier. The fusion and governance module is used to perform fusion processing when there are multiple compatible semantic operations on the same input data, and to perform degradation processing and output interpretable execution statistics when the capabilities of the model service provider do not meet the requirements.

[0016] Compared with existing technologies, the above technical solution has the following advantages: (1) Reduce model call cost. By executing ordinary relational predicates in advance, filterable data rows are eliminated first, and then semantic operators are triggered to call the model for the surviving data, avoiding a large number of meaningless model requests. At the same time, multiple rows are merged into a batch request within the same data block according to the grouping key of the model configuration and input features, further reducing the number of model calls and network interaction overhead.

[0017] (2) Reduce invalid reading and decoding of multimodal data. A delayed reading strategy is adopted for large binary fields such as images, video frames, and audio. The corresponding multimodal data is only read and decoded as needed after the ordinary filtering conditions have been executed and it has been confirmed that the target row really needs to participate in semantic calculation. This eliminates the waste of CPU, memory and bandwidth caused by full pre-reading in traditional solutions.

[0018] (3) Ensure the quality of structured output data. The type constraints, null constraints, enumeration constraints and check constraints in the database column definition are compiled into the structured output specification of the model. After the model is returned, the database side performs secondary verification and type conversion. For results that do not conform to the constraints, retry or repair is automatically performed to ensure that the data finally written into the query result is strictly consistent with the database schema.

[0019] (4) Supports the fusion execution of multiple semantic operations. When multiple semantic analysis tasks need to be executed on the same batch of data, the system identifies compatible operations and merges them into a single model call. Multiple result fields are returned at once through a composite output mode, and the data is split into corresponding output columns on the database side, avoiding repeated transmission of the same multimodal input data.

[0020] (5) Improve the observability and manageability of semantic computing. Semantic operators exist as independent physical operators in the query plan. Their execution process provides statistical indicators such as the number of model calls, the number of retries, the number of verification failures, and the amount of multimodal data read in the visualization output of the query plan, so that developers and operators can clearly understand the resource consumption and execution status of semantic computing.

[0021] (6) It has flexible degradation adaptability. When the capabilities of the model service provider do not meet the execution requirements of the semantic operator, the system automatically adjusts the execution mode according to the preset degradation strategy, and records the degradation event while ensuring that the query can continue to be executed, thus taking into account both availability and governance requirements. Attached Figure Description

[0022] Figure 1 This is a flowchart illustrating the method for generating an execution plan for a database semantic query in a preferred embodiment of the present invention. Figure 2 This is an architecture diagram of a database semantic query execution plan generation system in a preferred embodiment of the present invention. Detailed Implementation

[0023] The advantages of the present invention will be further illustrated below with reference to the accompanying drawings and specific embodiments.

[0024] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0025] The terminology used in this disclosure is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. The singular forms “a,” “the,” and “the” as used in this disclosure and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

[0026] It should be understood that although the terms first, second, third, etc., may be used in this disclosure to describe various information, such information should not be limited to these terms. These terms are used only to distinguish information of the same type from one another. For example, without departing from the scope of this disclosure, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0027] In the description of this invention, it should be understood that the terms "longitudinal", "lateral", "up", "down", "front", "rear", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer", etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this invention.

[0028] In the description of this invention, unless otherwise specified and limited, it should be noted that the terms "installation", "connection" and "linking" should be interpreted broadly. For example, they can refer to mechanical or electrical connections, or internal connections between two components. They can be direct connections or indirect connections through an intermediate medium. Those skilled in the art can understand the specific meaning of the above terms according to the specific circumstances.

[0029] In the following description, suffixes such as "module," "part," or "unit" used to denote elements are used only for the convenience of the description of the invention and have no specific meaning in themselves. Therefore, "module" and "part" can be used interchangeably.

[0030] See Figure 1 This is a flowchart illustrating the database semantic query execution plan generation method in a preferred embodiment of the present invention. In this embodiment, the database semantic query execution plan generation method is deployed within the database query engine or loaded as a database extension plugin. After receiving the SQL query statement submitted by the user, the database query engine parses, binds, optimizes, and executes it. The method described in this embodiment covers the entire process from query parsing to result output, elevating the semantic expressions in SQL into semantic operators that can be recognized, rewritten, and scheduled by the query optimizer, thereby achieving unified management of semantic computation within the database.

[0031] Specifically, step S100: Receive an SQL query statement containing semantic functions or semantic operators. Suppose a user submits an SQL query in a robot dataset management system. This query requests activity classification and summary generation for multiple operation videos stored in the database, with a structured JSON output. The query uses semantic functions for semantic classification (input is a sequence of video frames, output is activity category labels) and semantic summarization (input is a sequence of video frames, output is a natural language description), and includes filtering conditions based on video duration, acquisition site, and quality control status in the WHERE clause.

[0032] S200: Identifies semantic expressions in SQL query statements and generates semantic operator metadata for these expressions. This metadata describes the semantic operator's type, input / output specifications, model invocation configuration, and execution strategy. After receiving the SQL query statement, the database query engine enters the semantic expression recognition stage. The engine's parser scans the SELECT list, WHERE clause, HAVING clause, and ORDER BY clause of the SQL query, identifying expressions that call semantic functions or use semantic operators. Semantic function recognition methods include name matching (function names begin with a predetermined prefix or are registered in the semantic function registry) and type label matching (function parameter types or return types are marked as semantic types). For the example query above, the parser identifies two semantic function expressions, semantic classification and semantic summary, in the SELECT list, and three ordinary predicate expressions in the WHERE clause: video duration greater than a certain threshold, acquisition site equal to a certain identifier, and quality inspection status as qualified.

[0033] For each identified semantic expression, semantic operator metadata is generated. Semantic operator metadata is the core descriptive information of the semantic operator, recording its complete execution specifications. Taking the semantic classification operator as an example, its metadata records: the operator type is semantic projection (i.e., performing semantic calculations on each row of data and outputting a result value); the input columns include video frame sequence columns and video metadata columns; the input modality type is video frame sequence plus text; the target output mode is a single-value string (activity category label); the model invocation configuration specifies the target model service provider, model identifier, request timeout time, and concurrency limits; the execution strategy includes batch processing enable flag, maximum number of rows per batch, and degradation mode. The metadata structure of the semantic summarization operator is similar, but the target output mode is natural language text, and the prompt word template content is different. The generation process of semantic operator metadata is completed during the query compilation phase and does not consume model invocation resources.

[0034] S300: Separates ordinary relational expressions and semantic expressions in SQL query statements into ordinary relational operators and logical semantic operators, ensuring that operations such as ordinary predicate filtering, sampling, window sharding, and limiting the number of returns are executed before the logical semantic operators. Next, the execution plan is rewritten, separating ordinary relational computations and semantic computations into independent logical operators, arranged in ascending order of execution cost. For the example query above, in the original logical plan, ordinary column references and semantic function calls in the SELECT list are mixed in the same projection layer, and ordinary predicates and (hypothetically existing) semantic predicates in the WHERE clause are also mixed in the same filtering layer. The rewritten logical plan is broken down into a multi-layered structure: the bottom layer is the scanning operator, responsible for reading the basic columns (structured fields such as video identifier, duration, site identifier, and quality inspection status) from the video metadata table in the storage layer; the second layer is the ordinary filtering operator, which executes three conditions—video duration greater than a threshold, site identifier equal to a specified value, and quality inspection status being qualified—to filter out rows that do not meet the conditions; the third layer is the limit return quantity operator (if the query contains a LIMIT clause) or the sampling operator (if the query contains a TABLESAMPLE clause); the fourth layer is the ordinary projection operator, which extracts the input columns required by subsequent semantic operators (such as video frame sequence location information, text metadata, etc.) but does not actually read binary data; the fifth layer is the logical semantic operator, which executes the model calls for semantic classification and semantic summarization.

[0035] The key effect of this layered splitting is that the ordinary filtering operators are executed before the semantic operators, eliminating a large number of data rows that do not meet the duration, site, or quality inspection criteria before they even enter the semantic operators. Assuming the video metadata table has 10,000 records, after ordinary filtering, only about 200 rows might survive. Without splitting, the semantic operators would need to perform model calls on all 10,000 rows; after splitting, only 200 rows need to be called, reducing model requests by 98%.

[0036] S400: When a logical semantic operator depends on multimodal large-field data, after the ordinary relational operator has finished executing, perform on-demand reading or decoding on the multimodal data corresponding to the surviving data rows after filtering. When logical semantic operators rely on multimodal large-field data, a delayed read strategy is executed. In the example above, video frame sequence data is stored in a separate media storage table as binary large objects. The overhead of reading and parsing the video frame sequence is much greater than reading ordinary structured fields. During the ordinary projection operator stage, only the location information of the video frame sequence (such as media identifiers, group identifiers, and frame index lists) is read, without actually reading the video binary data. Only when the logical semantic operator determines that a model call needs to be executed, the binary data of the video frames is read on demand based on the location information. For multimodal data of video type, on-demand reading is further refined to decoding only the specific frames required by the semantic operators, rather than decoding the entire video stream. After decoding, the video frames are organized into an array of binary large objects in the order specified in the SQL query and passed to the subsequent model call stage.

[0037] S500: Compiles database output type constraints or user-specified structural schemas into model structured output constraints. Before model invocation, structured output constraints are compiled. When the target output of a semantic operator is structured data (such as the activity category label being an enumeration type and the semantic summary being a string of a specified length in the example above), the type definition, null value constraints, enumeration constraints, and check constraints of the target column in the database are compiled into the model's structured output specification. Specifically, for the activity category label column, the data type is read as string, null values ​​are not allowed, and the enumeration value set is "grab, place, assemble, detect, transport, standby" (six types). These constraints are compiled into a structured output format description that the model can understand. The compiled output constraints are sent to the model service provider along with the model request, ensuring that the model's output is constrained at the format level, reducing the probability of returning non-compliant results.

[0038] S600: During the physical execution phase, multiple lines of input within the same data block are merged into a single batch model request based on the semantic operator grouping key, and the returned results are split back into the corresponding original data lines based on the row identifier. Upon entering the physical execution phase, logical semantic operators are instantiated into physical semantic operators. Physical semantic operators use data blocks as the basic processing unit. A data block is the data transfer granularity within the database query engine, typically containing hundreds to thousands of rows of data. After receiving a data block, a physical semantic operator first calculates the semantic operator grouping key for each row within the block. The grouping key is jointly determined by the model service provider identifier, the model identifier, the prompt word template fingerprint, and the output pattern fingerprint. Rows with the same grouping key within the same data block are merged into a single batch model request. Taking the semantic classification operator in the example above, assuming the current data block contains 200 rows of data, these 200 rows use the same model and the same prompt word template, therefore having the same grouping key, and are merged into a single batch request containing 200 elements. The 200 prompt words (each carrying the input data of the corresponding row) are packaged into an HTTP request and sent to the model service provider; the model returns 200 results in a single response. The 200 returned results are split back into their corresponding rows based on the row identifier (row number or primary key value) and mounted onto the output column of that row.

[0039] S700: Performs structured validation on the results returned by the model and outputs the SQL query results. After the model returns results, structured validation is performed. The validation process includes JSON format parsing (if the model returns JSON text), data type conversion (converting the string "3.14" to the floating-point number 3.14), enumeration value checking (verifying if the returned category label is within a predefined enumeration set), null value constraint checking (verifying if fields that are not allowed to be null actually have values), and constraint validation (verifying if numeric fields meet range constraints, etc.). For the activity category label in the example above, the return value is checked to see if it is one of the six enumeration values; if not, the validation fails. Validated results are directly output as the corresponding column values ​​in the SQL query results.

[0040] S800: When the capabilities of the model service provider do not meet the requirements of the semantic operator metadata, perform corresponding degradation processing according to the degradation strategy in the semantic operator metadata. When the capabilities of the model service provider do not meet the requirements of the semantic operator metadata, degradation processing is performed according to the pre-configured degradation strategy. Degradation processing includes the following scenarios: If the model service provider does not support batch calls, it degrades to line-by-line calls, meaning each line within a data block is sent as a separate model request; if the model service provider does not support multimodal input, it degrades to sending only the text portion, with the database performing subsequent format validation and type conversion after the model outputs plain text; if the model service provider does not support structured output, a security policy determines whether to refuse execution and return an error message, or degrade to plain text output which is then parsed by the database. During degradation execution, the degradation event, the reason for degradation, and the actual execution method after degradation are recorded and written to the execution audit log.

[0041] By adopting the above technical solution, semantic computation and ordinary relational computation are separated and scheduled by elevating semantic expressions to first-class operators in the query plan. Pre-execution of ordinary predicates ensures that a large number of data rows are filtered before entering the semantic operators; delayed reading of multimodal data avoids invalid binary data reading and decoding; batch requests driven by group keys reduce the number of model calls and network overhead; compilation and verification of structured output constraints ensure consistency between the output results and the database schema; and the degradation strategy ensures that queries can continue to execute even when the model service provider's capabilities are insufficient.

[0042] Preferably, the multimodal large-field data upon which the aforementioned semantic operators rely covers four main types: binary large objects, video frames, audio clips, and document pages. Each type differs in its storage format, location method, and on-demand retrieval strategy within the database. Specifically, binary large objects are the most basic multimodal data type, typically used to store single images, raw binary data acquired by sensors, or preprocessed feature vectors. In the database, binary large objects are stored using the database standard binary field type, which can be inline storage or external storage. For smaller binary data (such as images of a few hundred KB), they can be directly stored within the table's rows; for larger binary data (such as high-resolution images of several MB), they are typically stored in a separate object storage table, with the business table only storing a reference identifier pointing to the object. When the semantic operator needs to consume a binary large object, it reads the corresponding binary content from the object storage table on demand based on the reference identifier, and then serializes it into the multimodal message format required by the model request. In robot data acquisition scenarios, binary large objects typically store camera snapshots at each workstation, time-series waveforms acquired by force sensors, or point cloud binary data generated by LiDAR. The process of reading video frames is complex, involving layered localization and on-demand decoding of the video stream. In the database, video data is not stored as a complete video file, but rather split into three layers according to video encoding standards: video stream records, video group records, and frame index records. The video stream records store video-level metadata and initialization parameters required for decoding. The video group records store the binary data of each compressed segment (corresponding to the GOP structure in the encoding standard) and the frame range it covers. The frame index records store the global sequence number, group identifier, intra-group sequence number, and business timestamp for each frame. When a semantic operator needs to consume a video frame, it first locates the global sequence number and group of the target frame in the frame index record according to the query conditions. Then, it reads the compressed data of that group and the initialization parameters of the video stream, calls the on-demand decoding function to decode only the target frame, and generates the corresponding image binary object. Throughout this process, other frames in the video stream that do not belong to the target frame are not decoded, avoiding the overhead of full decoding. In robot operation scenarios, a ten-second operation video might contain three hundred frames, while a semantic operator might only need five to ten frames from a specific moment. On-demand decoding can control the actual number of decoded frames within the required range. Audio segments are extracted from the audio stream stored in the database according to time windows. Audio data is stored in the audio stream record as a binary large object, which also stores audio-level metadata such as sampling rate, number of channels, and encoding format. When the semantic operator needs to consume an audio segment, it locates the audio sampling point corresponding to the time window from the binary data of the audio stream based on the start and end timestamps recorded in the frame index record or time index record, extracts it, and generates an independent audio binary object.The extraction process may involve audio encoding format conversion (e.g., decoding from the encoded format to the raw sampled data and then re-encoding to the target format) to ensure the output conforms to the input format required by the model service provider. In robotics scenarios, audio clips typically include recordings of voice commands in the operating environment, equipment operation sounds, or abnormal alarm audio. Semantic operators can perform semantic calculations such as speech recognition, voiceprint classification, or abnormal sound detection. Document page processing is suitable for structured or unstructured documents stored in the database, such as PDF format operation manuals, Word format work instructions, or scanned copies. Documents are stored in the document table as binary large objects, while also saving metadata such as document type, page number, and offset position of each page. When a semantic operator needs to consume a document page, it locates the offset position of the target page in the document's binary data based on the page index record, extracts the binary data of that page, and performs format conversion as needed (e.g., rendering a PDF page as an image binary object). In robot operation and maintenance scenarios, document pages typically include specific chapters of equipment maintenance manuals, screenshots of quality inspection standards, or scanned copies of training materials. Semantic operators can perform semantic calculations such as content extraction, compliance judgment, or key information extraction.

[0043] The four types of multimodal data mentioned above can be used independently or in combination within the same semantic operator. For example, a semantic operator for robot operation analysis might simultaneously consume keyframes from an operation video and corresponding audio segments, obtaining the required data according to video frame localization and audio segment extraction strategies respectively, and then assembling the image binary object and audio binary object together into the multimodal input content requested by the model. As another example, a semantic operator for quality inspection might simultaneously consume product photos (large binary objects) and standard pages from the product manual (document pages), combining the two and sending them to the model for comparative analysis.

[0044] Four main multimodal data types were designed with corresponding storage structures and on-demand reading strategies. Specifically, large binary objects are read on demand using reference identifiers; video frames are located and decoded only the required frames using hierarchical indexing; audio clips are extracted from the stream by time windows; and document pages are located and rendered by page indexing. All data types follow a lazy reading principle, only being read or decoded after the semantic operator confirms the need to execute a model call, avoiding unnecessary large field processing overhead during the ordinary relation filtering stage. The combined consumption capability of multiple modal types enables the semantic operator to handle complex semantic computation tasks involving various data types such as images, text, and audio.

[0045] Optionally, when the input to the semantic operator is a video frame, the target frame is located through the hierarchical index structure of the video stream, on-demand decoding is performed, and the decoding results are organized into a binary large object array according to the array order specified in the SQL query. Specifically, the video stream is organized and stored in the database using a three-level index structure. The first level is the video stream record, with one record corresponding to each video stream, storing video-level metadata (such as encoding format, resolution, frame rate, and total number of frames) and decoding initialization data (such as the sequence parameter set and image parameter set specified by the video encoding standard). The second level is the video group record, where each video stream is split into multiple video groups according to the inter-coordinate relationship between encoded frames, with one record corresponding to each group, storing the compressed video binary data of the group and the frame range it covers (starting global frame number and ending global frame number). The third level is the frame index record, with one record corresponding to each frame, storing the global frame number, the video group identifier, the frame number within the group, and the business timestamp.

[0046] When the semantic operator needs to consume video frames as input, hierarchical localization and on-demand decoding are performed according to the following process.

[0047] First, the required frames are determined based on the input specification of the semantic operator. The input specification can specify a specific list of frame numbers (e.g., frame 10, frame 50, frame 100), a time window (e.g., all frames from timestamp A to timestamp B), or a sampling strategy (e.g., taking one frame every N frames). Regardless of the specification, it is ultimately parsed into a set of explicit global frame numbers. For example, suppose the input specification of the semantic operator is "take frames 100 to 120 from video stream cam_01, taking one frame every two frames," which is parsed into a global frame number set {100, 102, 104, 106, 108, 110, 112, 114, 116, 118, 120}, a total of 11 frames.

[0048] Then, based on the global frame number of the target frame, the video group identifier and intra-group frame number corresponding to each frame are searched in the frame index record. For the 11 frames in the example above, the frame index record is queried one by one to obtain the video group identifier and intra-group frame number to which each frame belongs. The query results may show that: frames 100 to 108 belong to video group gop_005, frames 110 to 118 belong to video group gop_006, and frame 120 belongs to video group gop_007. At this point, the complete location information of each target frame is obtained.

[0049] Next, the target frames are grouped according to video groups. The grouping results are as follows: gop_005 contains 5 target frames (even-numbered frames from sequence 100 to 108), gop_006 contains 5 target frames (even-numbered frames from sequence 110 to 118), and gop_007 contains 1 target frame (sequence number 120). The purpose of grouping is to prepare for subsequent batch decoding: multiple target frames belonging to the same video group can share a single group data reading and a single initialization decoding process.

[0050] Read the compressed data of each target group and the initialization data of its corresponding video stream. For gop_005, read the compressed binary data of the group from the video group record and the initialization data (sequence parameter set and image parameter set) from the video stream record. Then, call the on-demand decoding function, sending the initialization data and the compressed data of the group to the decoder, decoding only the five target frames (frames 100, 102, 104, 106, and 108) in gop_005, skipping the other frames in the group. After decoding, each of the five target frames generates an image binary object. Similarly, the five target frames of gop_006 and the one target frame of gop_007 are decoded using their respective group data.

[0051] During the entire decoding process, only the target frames are decoded; the remaining frames are not decoded. For example, video group gop_005 might contain 30 frames of encoded data (frames 90 to 119), but only the five target frames are decoded, skipping the remaining 25 frames. This on-demand decoding strategy offers particularly significant performance gains when the number of target frames is much smaller than the total number of frames in the group.

[0052] After decoding, the binary image objects corresponding to each target frame are arranged according to the array order specified in the SQL query, generating the final large binary object array. The SQL array order refers to the frame arrangement order explicitly specified by the user in the SQL query through array construction syntax or frame number list. For example, if the frame number list specified by the user in the SQL query is [100, 102, 104, 106, 108, 110, 112, 114, 116, 118, 120], then in the generated large binary object array, the first element corresponds to the image of frame 100, the second element corresponds to the image of frame 102, and so on, with the eleventh element corresponding to the image of frame 120.

[0053] Maintaining the order of the SQL array is crucial because the semantic results returned by the model (such as classification labels, summary text, or structured annotations) need to correspond one-to-one with the input frames, and this correspondence is determined by the array order. If the order of the decoded binary large object array is inconsistent with the order specified in the SQL, the results returned by the model will not correctly correspond to the original frames, leading to errors in subsequent processing. Therefore, when generating the binary large object array, it is not arranged according to the natural decoding order within the video group, but rather rearranged according to the frame sequence number order specified in the SQL query.

[0054] For frames from the same video group, the decoder's natural output order is usually consistent with the frame sequence number within the group, which largely matches the SQL array order, requiring no additional rearrangement. However, for frames spanning multiple video groups, the decoder outputs them sequentially by group, while the frame sequence number order specified by the SQL may differ from the group order (e.g., the SQL first requests frame 120 in gop_007, then frame 100 in gop_005). In this case, a rearrangement operation must be performed on the decoding results to ensure that the element order in the binary large object array strictly matches the SQL array order. A three-level index structure achieves precise hierarchical positioning of video frames, grouping and batch decoding reduces redundant reading of group data, decoding only the target frame avoids the overhead of full decoding, and maintaining the SQL array order ensures the correct frame correspondence between the model input and output. All of the above processes are completed internally within the database, eliminating the need to export video data for external processing and guaranteeing end-to-end execution of semantic operators within the database query plan.

[0055] On the other hand, when semantic operators require structured output, output type constraints are extracted from the database column definitions and compiled into a structured output specification that the model service provider can understand. Constraints in the database column definitions come from at least one of type declarations, null constraints, enumeration constraints, and check constraints. The compilation methods for each type of constraint and their manifestation in model calls are explained below. Type declarations are the most basic constraint in database column definitions, specifying the data types that the column is allowed to store. Common type declarations include integers, floating-point numbers, strings, booleans, date / time, JSON objects, and arrays. When the target output column of a semantic operator has a specific type declaration, this type is mapped to the type field in the model's structured output specification during the compilation phase. For example, if the target column is an integer, the corresponding field in the compiled output specification is marked as an integer; if the target column is a string, it is marked as a string; if the target column is a JSON, it is marked as an object, and its internal field structure is further expanded. The mapping of type declarations ensures that the values ​​returned by the model are compatible with the database column definitions at the data type level, avoiding type mismatch errors during subsequent insertions. Null constraints specify whether the column is allowed to store null values. In databases, column definitions express this constraint by including the "not nullable" keyword. When a target column is defined as not nullable, the field is marked as required in the compiled output specification, meaning the model must return the value of this field and cannot output empty or missing values. When a target column allows null values, the field is marked as optional, and the model can choose not to return the field if the result is uncertain, treating it as a null value. Compiling null constraints allows the model to be aware of which fields are required when generating output, reducing downstream processing anomalies caused by null values. Enumeration constraints specify the set of values ​​that a column can store. In databases, enumeration constraints are usually implemented through check constraints, such as limiting the values ​​of a column to within a predefined set of strings. When the target output column of a semantic operator is restricted by an enumeration constraint, the set of enumeration values ​​in the check constraint is parsed and compiled into an enumeration type field in the model's structured output specification. For example, if the check constraint of the target column limits the values ​​to six types: "grab, place, assemble, detect, transport, standby," the type of this field in the compiled output specification is marked as enumeration, and the set of optional values ​​is the above six types. When generating output, the model is constrained to choose only from these six values ​​and will not return illegal values ​​outside the enumerated range. Check constraints are a more general column-level or table-level constraint that can express arbitrary Boolean conditions. In databases, check constraints take various forms, such as range constraints for numeric fields (values ​​greater than zero and less than or equal to one hundred), length constraints for string fields (character length not exceeding fifty), time range constraints for date fields (dates not earlier than a certain start date), and joint constraints between multiple fields (the value of field A must be earlier than the value of field B).When the target output column of a semantic operator is subject to check constraints, the conditional expressions in the check constraints are parsed and converted into constraint descriptions expressible in the model's structured output specification. For range constraints and length constraints, they are compiled into minimum, maximum, minimum, or maximum length parameters in the output specification; for complex conditional expressions, they are converted into natural language descriptions and appended to the field descriptions for the model to reference when generating output. By compiling type declarations, null constraints, enumeration constraints, and check constraints in the database column definitions into the model's structured output specification, the automatic transfer of database schema constraints to model output constraints is achieved.

[0056] In practical applications, a target output column is often subject to multiple constraints simultaneously. Taking a labeling result table in a robot operation analysis scenario as an example, this table contains the following definitions: Activity Category (string type, not allowed to be empty, enumeration constraint: one of six activity types), Confidence Score (floating-point type, not allowed to be empty, check constraint: value between zero and one), Operation Description (string type, allowed to be empty, check constraint: length not exceeding 500 characters), and Anomaly Flag (Boolean type, allowed to be empty). Compiling the output constraints for these four columns separately generates the following structured output specification: The activity category field is a required enumeration type, with six optional activity types; the confidence level field is a required floating-point number type, with a minimum value of zero and a maximum value of one; the operation description field is an optional string type, with a maximum length of 500; and the exception flag field is an optional boolean type. After compilation, the structured output specification is sent to the model service provider as part of the model request. Different model service providers support different structured output specification formats, which are adapted during compilation based on the capabilities of the target model provider. For service providers that support JSON schema specifications, the output specification is compiled into a JSON format type description; for service providers that support function call formats, the output specification is compiled into a function parameter definition format; for service providers that do not support structured output, it degenerates into a plain text output mode, embedding constraint information in prompts for the model to follow automatically, and performing secondary validation on the database side. After the model returns the results, structured parsing and constraint validation are performed. The parsing process parses the raw text returned by the model (usually in JSON format) into structured objects within the database. Then, each field is checked one by one to ensure it meets the compiled constraints: whether the type matches the target column type, whether fields that are not allowed to be null have values, whether the values ​​of enumerated fields are within the allowed set, and whether the conditions in the constraints are met. For the annotation results in the example above, it is checked whether the activity category is one of the six, whether the confidence level is within the range of zero to one, and whether the length of the operation description does not exceed 500 characters. Records that pass all validations are output as normal SQL query results, while records that fail validations are entered into the exception handling process.

[0057] In a preferred embodiment, after the semantic operator performs structured validation on the model's returned results, some rows may fail validation. In this case, it is necessary to perform retry repair or abnormal row recording operations on the rows that failed validation, according to the error handling strategy pre-configured in the semantic operator's metadata. Validation failures can be categorized into the following types based on their causes: Format-level failures refer to the content returned by the model being unable to be parsed into the expected structured format. For example, the target format is JSON, but the model returns a plain text fragment, or the JSON text contains syntax errors (such as missing closing brackets, extra commas, etc.). Type-level failures refer to the field value's type not matching the target column definition. For example, the target column is defined as an integer type, but the model returns a string value, or the target column is defined as a floating-point number type, but the model returns non-numeric text. Enumeration-level failures refer to the field value not being within a predefined enumeration set. For example, the activity category field requires selection from six specified types, but the model returns a label that is not in the set. Constraint-level failure refers to a field value not meeting the check constraints. For example, the confidence field requires a value between zero and one, but the model returns 1.5, or the operation description field requires a length of no more than 500 characters, but the model returns excessively long text.

[0058] For the above-mentioned types of verification failures, the different retry and repair strategies are explained in detail below: The first strategy is overall retries. When the proportion of rows that failed validation to the total number of rows in the current data block is less than a preset threshold, the rows that failed validation are reconstructed into a new batch of model requests, and the entire process is retried. The retry request can include a prompt indicating the constraints from the previous failure, such as appending "Please ensure the confidence value is between zero and one" to the end of the prompt, guiding the model to adhere to the constraints during regeneration. The number of overall retries is limited by a maximum number of retries; rows that still fail after exceeding this limit are transferred to the abnormal row record process.

[0059] The second strategy is partial repair. When the validation failure only involves issues that can be automatically corrected, the model's return value is directly corrected on the database side without needing to re-call the model. Partial repair is suitable for the following situations: cases where the type can be implicitly converted (e.g., the string "0.85" can be converted to the floating-point number 0.85); cases where the value is out of range but can be corrected by truncation (e.g., a confidence value of 1.2 is truncated to 1.0, and a negative value is truncated to 0.0); cases where enumeration values ​​have approximate matches (e.g., the model returns "pick," but the nearest valid value in the enumeration set is "grab," so "pick" is corrected to "grab" using a predefined alias mapping table); and cases where the string is too long but can be corrected by truncation (e.g., when the operation description exceeds 500 characters, the first 497 characters are truncated and an ellipsis is appended to the end). After partial repair, constraint validation is performed again on the corrected value. If the corrected value satisfies all constraints, the validation is considered successful.

[0060] The third strategy is a hybrid approach, which first attempts partial repair, and then retryes the entire process for rows that cannot be partially repaired. The hybrid approach's workflow is as follows: each row that failed validation is assessed to determine if it can be partially repaired. Rows that can be repaired are directly corrected in the database and marked as repaired; rows that cannot be repaired are collected, retry requests are constructed, and sent to the model service provider to regenerate the results. The retry results are then subjected to structured validation again, and rows that still fail are transferred to the abnormal row record process.

[0061] For rows that still fail to be validated after retrying and repair, an exception row recording operation is performed. Exception row recording operations include one or more of the following methods: - Set the value of a field that fails validation to null.

[0062] When the target column allows null values, set the value of the field that failed the validation to null, while retaining the normal results for the remaining fields in the row. Setting it to null is the lightest exception handling method, suitable for scenarios where individual fields occasionally fail validation but do not affect the overall query results.

[0063] - Write failure information to the error column.

[0064] Add one or more error information columns to the query results to record the field name, reason for failure, original return value, and processing operation for the validation failure. For example, the error column could record "Activity category field validation failed: return value 'Move' is not in the enumeration set and has been set to null". Adding an error column ensures that the query results retain complete validation failure information, facilitating subsequent troubleshooting and statistics.

[0065] - Write the abnormal rows to the exception table.

[0066] Complete rows of data that failed validation (including original input columns, the original results returned by the model, the fields that failed validation, and the reasons for the failure) are persisted to an exception table in the database. The exception table exists as a separate physical table, independent of the normal query results. Records in the exception table can be read and processed by subsequent remediation or manual review processes. Writing to the exception table does not affect the output of normal query results; the query results only contain rows that passed validation (or rows that failed validation but have been corrected to acceptable values).

[0067] For example, a semantic operator performs robot operation activity classification on 200 rows of data, and the model returns 200 results. After structured validation, 190 rows passed completely; 5 rows had activity category fields returning values ​​outside the enumeration set, but this could be partially corrected using alias mapping; 3 rows had confidence field values ​​out of range, but this could be partially corrected using truncation; and 2 rows returned unparseable JSON text, requiring a full retry. After performing partial corrections on rows 5 and 3 respectively, the validation passed; for row 2, a full retry was performed, after which 1 row passed and 1 row still failed. Ultimately, 199 rows passed validation and were output normally, while the confidence field of row 1 was set to null and the failure information was written to the error column. Simultaneously, detailed information about the validation failure (field name, original return value, reason for failure, and processing operation) was recorded in the execution audit log.

[0068] In summary, by classifying failure types, providing two repair strategies—overall retry and partial repair—and an exception log mechanism, a complete closed-loop processing mechanism for model output verification failures has been constructed. The partial repair strategy directly corrects automatically repairable values ​​at the database level, avoiding unnecessary model re-call overhead. The overall retry strategy guides the model to correct its output by adding constraint prompts to the prompt words, improving the success rate of retrying. The exception log mechanism ensures the complete traceability of verification failures, providing a basis for subsequent data quality audits and manual review.

[0069] Preferably or optionally, physical semantic operators use data blocks as the basic processing unit during the physical execution phase. They merge multiple rows of input within the same data block into a single model call by calculating the semantic operator grouping key. Specifically, a data block is the basic unit for data transfer between operators in the database query engine pipeline. A data block typically contains hundreds to thousands of rows of data, each row containing all column values ​​corresponding to that row. After receiving a complete data block from an upstream operator, the physical semantic operator performs grouping and batching operations within that data block. Batching operations are strictly limited to the current data block, not crossing data block boundaries, query pipeline stages, different SQL queries, or different user sessions. This design is because data rows in different data blocks may come from different query conditions or different security policies; cross-data block batching may lead to data confusion or permission violations; cross-query batching introduces dependencies between queries, increasing the complexity of scheduling and error recovery; and cross-user batching may violate data isolation and privacy protection requirements.

[0070] The semantic operator grouping key is determined by the following four pieces of information: - Model service provider identifier The model service provider identifier is used to distinguish different model service providers. In a database environment, different semantic operators may be configured to use different model service providers (such as different cloud service providers or different on-premises model services). The provider identifier in the grouping key ensures that only rows using the same model service provider will be batched.

[0071] - Model Identifier Model identifiers are used to distinguish different models from the same service provider. The same model service provider may deploy multiple models (such as a small-parameter model for classification and a large-parameter model for summarization). The model identifier in the grouping key ensures that only rows that call the same model are batched.

[0072] - Prompt word template fingerprint A cue word template fingerprint is a summary value calculated from the cue word template used by the semantic operator. The cue word template determines how the input data is organized into the content format requested by the model; different semantic tasks (such as classification and summarization) typically use different cue word templates. The cue word template fingerprint is obtained by calculating a hash value from the template text; fingerprints are the same for the same template and different for different templates. Using the fingerprint, rather than the complete template text, as part of the grouping key ensures the accuracy of grouping decisions while avoiding the memory overhead of carrying large chunks of text in the grouping key.

[0073] - Output mode fingerprint The output pattern fingerprint is a summary value calculated from the target output pattern of a semantic operator. Different output patterns (such as single-value string output, JSON object output, and boolean value output) correspond to different structured output specifications. The output pattern fingerprint in the grouping key ensures that only rows using the same output specification are batched.

[0074] The four pieces of information are combined to form a complete grouping key. Within the same data block, rows with identical grouping keys are grouped into the same group, and multiple rows of input within the same group are merged into a single model call. A concrete example illustrates the batching process: Assume the current data block contains 500 rows of data, the physical semantic operator is a semantic classification operator, and it uses model X, prompt word template T1, and output pattern S1 from model service provider A. Simultaneously, the query also contains a semantic summarization operator, using model Y, prompt word template T2, and output pattern S2 from model service provider A. The grouping key is calculated for each of the 500 rows of data. 300 rows have the grouping key (A, X, T1 fingerprint, S1 fingerprint) and are grouped into the semantic classification group; the other 200 rows have the grouping key (A, Y, T2 fingerprint, S2 fingerprint) and are grouped into the semantic summarization group.

[0075] For the 300 rows grouped for semantic classification, they are merged into a single batch model request. Each batch request contains 300 elements, each corresponding to one row of input data (including text parameters after prompt rendering and multimodal data). These 300 elements are packaged into a single HTTP request and sent to model X of model service provider A. The model returns 300 results in a single response. The entire process involves only one network request and one model call, rather than 300 independent requests and calls.

[0076] Similarly, the 200 rows of semantic summary groups are merged into a single batch request sent to model Y, resulting in one network request and one model call. Therefore, the 500 rows of data result in a total of two model calls, not 500.

[0077] After the model returns the batch results, it splits the results back into the corresponding original data rows based on the row identifiers. A row identifier is a unique sequence number (a consecutive integer starting from the beginning of the data block) for each row within the data block. The row identifier for each element is recorded when constructing the batch request. The model returns results in the order of the elements in the request, and each result is attached to the correct row based on the correspondence between elements and row identifiers. During the splitting process, it is not necessary to parse the row identifier information in the model's returned results (the model's returned results themselves do not contain row identifiers); instead, the correspondence is implicit based on the element order during request construction. Within the same data block, when some rows are marked as skipped due to ordinary predicate filtering or NULL value handling, these rows do not participate in the calculation of the grouping key or the batching process. For example, of the 500 rows mentioned above, 50 rows are marked as skipped because the input column values ​​are empty, and the remaining 450 rows participate in grouping and batching. The semantic output column for skipped rows is directly set to null, without triggering a model call. The number of skipped rows is recorded in the execution statistics for subsequent interpretability display. In some cases, the number of rows with the same grouping key within the same data block may exceed the maximum number of rows allowed in a single batch by the model service provider. In this situation, the rows within the group are split into multiple sub-batches based on the maximum batch size, and each sub-batch sends a separate model request. For example, if the maximum batch size is 100 rows and the current group contains 300 rows, it is split into three sub-batches, each sending a separate request. The split results are still reconstructed from the original rows according to their row identifiers, without affecting the correctness of the query results. By calculating the semantic operator grouping key within the data block and merging rows in the same group into a single batch model call, the number of model calls and network interaction overhead are significantly reduced. The grouping key is determined by four pieces of information: the model service provider identifier, the model identifier, the prompt word template fingerprint, and the output pattern fingerprint, ensuring the correctness of the batch merging (rows within the same group indeed require the same model call configuration). The batch merging operation is strictly limited to within the data block, without introducing dependencies across data blocks, queries, or users, ensuring the isolation and security of query execution.

[0078] On the other hand, when the same SQL query performs multiple semantic operations on the same input data, compatible semantic operations are identified and fused into a composite semantic operator. Multiple result fields are returned simultaneously through a single model call, and then split into corresponding SQL output columns or predicate results on the database side. For example, in a typical query scenario for robot dataset management, a user might want to perform multiple semantic analyses simultaneously on the same operation video. For instance, a single SQL query might require performing activity classification (outputting activity category labels), anomaly detection (outputting a boolean value indicating the presence of anomalies), quality scoring (outputting an integer score from one to five), and operation summary (outputting a natural language description) on each operation video. Without fusion, these four semantic operations would generate four independent semantic operators, each initiating a separate model call. The frame data of the same video would be read and decoded four times, with each of the four requests carrying the same video frame input but different prompt word templates. This significantly reduces the number of model calls and the overhead of redundant processing of multimodal data without changing the query semantics. Before fusion, each of the N independent operations required one model call and one multimodal input transmission. After fusion, only one model call and one multimodal input transmission are required. The multiple result fields returned are split into corresponding SQL output columns or predicate results on the database side, which has no impact on the user-visible behavior of the query.

[0079] In this embodiment, the core of the fusion mechanism lies in identifying the compatibility between multiple semantic operations and merging them into a single call. Compatibility is determined from the following dimensions: Model service provider dimension: Multiple semantic operations participating in the fusion must use the same model service provider; otherwise, they cannot be processed in the same request. Model identification dimension: Multiple semantic operations participating in the fusion must use the same underlying model. Different models have different output formats and capabilities, and cannot be merged into the same call. Security policy dimension: The security levels of the multiple semantic operations participating in the fusion must be compatible. For example, sensitive data requiring processing by an internal network model is not allowed to be mixed with non-sensitive data that can be processed by a public network model in the same request. Context window dimension: The total amount of input data (including prompt text and multimodal data) for the multiple semantic operations participating in the fusion must not exceed the model's context window capacity limit. Input data dimension: The multiple semantic operations participating in the fusion must operate on the same input data or highly overlapping input data. If two operations require completely different video streams or frames from completely different time periods, the fusion benefit is limited and may increase unnecessary input data volume.

[0080] After multiple semantic operations pass compatibility checks, a fusion operation is performed. The core step of the fusion operation is to construct a composite output pattern. The composite output pattern merges the target output fields of each original semantic operation into a unified structured output specification. Taking the four semantic operations in the example above as an example: the original output pattern of the activity classification operator is a single-value string (activity category label); the original output pattern of the anomaly detection operator is a boolean value (whether an anomaly exists); the original output pattern of the quality scoring operator is an integer (one to five); and the original output pattern of the operation summary operator is a string (natural language description). The fused composite output pattern is a JSON object containing four fields: activity_type (enumeration type, one of six activity categories), has_anomaly (boolean type), quality_score (integer type, range one to five), and summary (string type, maximum length 500 characters).

[0081] After the composite output pattern is constructed, the prompt word templates of the four original operations are merged into a single composite prompt word template. This composite prompt word template describes all four task requirements in a single prompt word, instructing the model to output all four fields simultaneously in a single response. The merged prompt word constrains the model's output format through structured output specifications, ensuring that the returned JSON object contains all four fields and that each field satisfies its corresponding type and range constraints.

[0082] The fused physical semantic operators perform batching and model calls using the same DataChunk grouping key mechanism as the individual semantic operators. For each line of input data within a data block, only one model call is needed to obtain all four semantic results. Taking the above scenario as an example, assuming the data block contains 100 lines of video data, before fusion, 400 model calls were required (100 lines multiplied by 4 operations), while after fusion, only 100 model calls are required (100 lines, one call per line returning four fields), reducing the number of model calls by 75%. More importantly, the frame data of each line of video only needs to be read and decoded once (instead of four times as before fusion), reducing the processing overhead of multimodal data to one-quarter of the original.

[0083] After the model returns a composite result, the result is split on the database side. The splitting process maps each field in the JSON object returned by the model to its corresponding SQL output column or predicate result. Taking the example above: the `activity_type` field in the composite result is mapped to the activity category output column in the SQL query; the `has_anomaly` field, if it appears in the WHERE clause as a filtering condition, is mapped to the boolean result of the semantic predicate for row filtering; the `quality_score` field is mapped to the quality score output column; and the `summary` field is mapped to the operation summary output column. The splitting process is completed during the output processing stage of the physical semantic operator. The split field values ​​are then attached to the corresponding row's output column, and subsequent query execution processes are unaware of the fusion operation.

[0084] Special cases may arise under different operating conditions. For example, when the validation results of some semantic operations fail while others pass, validation and exception handling are performed independently for each field: fields that pass validation are output normally, while fields that fail validation are handled according to their respective error handling strategies, resulting in retry repair or abnormal row records. The validation failure of one field does not affect the output of other fields in the same row.

[0085] If the results of certain semantic operations are found to be unnecessary during query execution (e.g., due to subsequent conditional filtering or projection pruning), the generation of output fields for these operations can be skipped during the fusion stage, and the corresponding output requirements can be omitted in the compound prompt words, further reducing the output overhead of the model.

[0086] In one optional embodiment, when the capabilities of the model service provider do not meet the execution requirements declared in the semantic operator metadata, corresponding degradation processing will be performed based on the unsupported capability type. The goal of degradation processing is to ensure that queries can still be executed as much as possible under the condition that the capabilities of the model service provider are limited, while ensuring that the degradation behavior is traceable through audit logs. It generally falls into the following three scenarios: The first degradation scenario is when the model service provider does not support batch calls. Some model service providers only accept single requests and do not support carrying multiple input elements in a single request. When the metadata of the semantic operator is marked as batch processing enabled, but the capability declaration of the target model service provider does not include batch call support, the degradation is to line-by-line call mode. In line-by-line call mode, the physical semantic operator constructs a separate model request for each row of data in the data block and sends it, with each row request waiting for a response independently. Line-by-line calls do not change the semantic correctness of semantic computation; each input row still uses the same prompt word template and the same output constraints, only changing the batch granularity of the requests. The impact of line-by-line call degradation on query performance is mainly reflected in the increase in the number of model calls and network interactions. Assuming the data block contains 300 rows of data, in batch mode only one model call and one HTTP request are needed, while after degradation to line-by-line calls, 300 model calls and 300 HTTP requests are required. Although the number of calls increases, the optimization of ordinary predicate preposition and multimodal data delayed reading is still maintained, ensuring that only the data rows that survive the filtering are triggered to trigger model calls. In line-by-line call mode, the execution statistics record that the actual number of model calls is 300 (instead of 1 in batch mode), and the reason for the downgrade is "the model service provider does not support batch calls".

[0087] The second degradation scenario occurs when the model service provider does not support multimodal input. Some model service providers only accept plain text input and do not support carrying binary data such as images, video frames, and audio in the request. When the metadata of the semantic operator declares a multimodal input requirement (such as the input modality containing video frames or large binary objects), but the capability declaration of the target model service provider does not include multimodal input support, the degradation is to plain text output with post-validation mode. In plain text output with post-validation mode, multimodal data is no longer sent to the model. Instead, relevant information about the multimodal data is embedded in the prompt words in text form. Specifically, the text description information of the multimodal data (such as the business timestamp of video frames, filenames or metadata of images, duration of audio segments, etc.) is extracted, and these text descriptions are used as context information for the prompt words. The model generates output based on the text description (rather than the actual multimodal data). After the model returns the results, more stringent validation is performed on the database side because the accuracy of model output in plain text mode is usually lower than that in multimodal mode. After the verification is passed, the result is marked as "degraded output" in the output, prompting the user that the result was not generated based on actual multimodal data.

[0088] To illustrate with a concrete example: Suppose a semantic operator requires activity classification of robot operation video frames, but the target model service provider does not support image input. After degradation, textual metadata such as the video frame's business timestamp, camera identifier, and frame number are embedded in prompt words. The model infers the activity type based on this textual information and returns the result. Since the model cannot actually observe the video footage, the confidence level of the returned classification result is usually low. The returned result is marked as "degraded output," and the reason for degradation is recorded in the execution audit log as "The model service provider does not support multimodal input; it has been downgraded to text description mode."

[0089] The third degradation scenario occurs when the model service provider does not support structured output. Some model service providers only support plain text output and do not support returning results in a predefined structured format (such as JSON schema). When the semantic operator's metadata declares a requirement for structured output, but the target model service provider's capability declaration does not include support for structured output, the degradation method is determined based on the security policy configuration.

[0090] When the security policy allows for downgrade, the model downgrades to plain text output and then validates the output. After the model returns plain text results, it attempts to parse the plain text into the expected structured format on the database side. Parsing methods include regular expression extraction, JSON text detection, and natural language parsing. If parsing is successful, the same constraint validation as in normal mode is performed on the parsed result; if parsing fails, the validation is considered failed, and the process proceeds to the abnormal row record flow.

[0091] When the security policy does not allow downgrades, the semantic operator is refused execution and an error message is returned. The error message explains the specific unsupported capability type (structured output) and suggests alternatives (such as changing to a model service provider that supports structured output or adjusting the query to plain text mode). Refusal to execute ensures that in security-sensitive scenarios, downgrades will not lead to uncontrollable output quality issues.

[0092] The three degradation scenarios can be combined. For example, if a model service provider does not support batch calls, multimodal input, and structured output simultaneously, then line-by-line calls, plain text output with post-validation, and plain text parsing can be applied concurrently. After combining degradation strategies, all reasons and strategies for degradation are recorded in the execution audit log, and the combined impact of the combined degradation is reflected in the degradation flag of the query results. These three targeted degradation strategies ensure that semantic operators can continue to execute or provide clear error feedback even when the model service provider's capabilities are insufficient. Line-by-line call degradation maintains the correctness of semantic computation but increases the number of calls; plain text output with post-validation degradation replaces actual data with text descriptions when multimodal input is unavailable, sacrificing some accuracy for the continued execution of the query; and rejection degradation avoids uncontrollable output quality issues in security-sensitive scenarios. The auditable recording of all degradation events provides a basis for subsequent operation and maintenance analysis and configuration optimization.

[0093] All degradation events are recorded in the execution audit log. The audit log contains the following information: semantic operator identifier, target model service provider identifier, degradation trigger reason (specific unsupported capability type), execution strategy adopted after degradation, comparison of actual model call counts before and after degradation, impact marker of degradation on result quality (normal output or degraded output), and timestamp of degradation occurrence. The persistence of the audit log allows operations personnel to review the specific circumstances of each degradation, assess its impact on query results, and adjust the model service provider configuration or replace the service provider accordingly.

[0094] In another optional embodiment, execution statistics of semantic operators are displayed in the interpretable output of the query execution plan, enabling developers and operations personnel to intuitively understand the resource consumption and execution status of semantic computation during query execution. Specifically, database query engines typically provide visualization output functions for query plans (such as the EXPLAIN statement in SQL or the query engine's profiling tool) to display the execution plan structure and runtime statistics of each operator. In traditional solutions, semantic functions are hidden in the query plan as ordinary user-defined functions, and the EXPLAIN output only displays a general function call node, failing to show the specific number of model calls, failure scenarios, and resource consumption. This embodiment treats semantic operators as independent physical operators in the query plan, designing a dedicated statistical metric collection and display mechanism for them. Physical semantic operators are displayed as independent nodes in the interpretable output of the query plan. Each physical semantic operator node displays the following basic information: operator name (e.g., PhysicalSemanticProjection, PhysicalSemanticFilter, PhysicalSemanticExtract, etc.), operator type (semantic projection, semantic filtering, semantic extraction, or semantic rearrangement), target model service provider identifier, and model identifier. Before query execution, the EXPLAIN output displays static information of the semantic operators in the logical plan (e.g., operator type, input columns, and output columns); after query execution, the profile output overlays statistical metrics collected during runtime.

[0095] It is understood that, in this embodiment, the statistical indicators may cover the following dimensions: - Number of model calls The model call count metric represents the total number of model requests initiated by the physical semantic operator during actual execution. This metric reflects the actual computational cost of the semantic operator. In DataChunk batch processing mode, the number of model calls is much less than the number of input rows (because multiple rows with the same grouping key are merged into one call). For example, if a data block contains 500 input rows, but only 2 model calls occur after batching, the model call count metric will show as 2. This metric allows developers to intuitively evaluate the effectiveness of batch processing optimization. If the number of model calls is close to the number of input rows, it indicates that the batching effect is not ideal, and developers can check whether the grouping key is too fragmented or whether the number of rows in the data block is too small.

[0096] - Number of retries The retry count represents the total number of model retry requests triggered due to structured validation failures. This metric reflects the quality of the model output and the degree of matching with the structured constraints. Zero retries indicate that all model outputs passed validation on the first attempt; a high number of retries suggests that the model's output format may deviate significantly from the structured constraints. Developers can check whether the prompt word template adequately describes the output constraints, or whether the model service provider's structured output capabilities are sufficient.

[0097] - Number of verification failures The validation failure count shows the number of fields or rows that ultimately failed (failed after retries) in structured validation. This metric reflects the number of abnormal outputs that cannot be fixed by retries. When the number of validation failures is high, developers need to pay attention to the failure details recorded in the exception table to determine whether it is necessary to adjust the constraints in the database column definitions or change the model service provider.

[0098] - Multimodal data read volume Multimodal data read volume is the total amount of binary large objects, video frames, audio clips, or document pages actually read during the execution of physical semantic operators (in bytes or frames). This metric reflects the actual effectiveness of the delayed read strategy. If the multimodal data read volume is much smaller than the total amount of all multimodal data in the database, it indicates that the ordinary predicate prepositioning and delayed read strategies have effectively reduced unnecessary overhead from processing large fields.

[0099] In addition to the core metrics mentioned above, the statistical information may also include the following supplementary metrics: Input row count represents the total number of rows in the data block received by the physical semantic operator from the upstream operator; Skipped row count represents the number of rows skipped due to empty input columns or ordinary predicate filtering; Batch group count represents the number of different grouping keys formed within the same data block, reflecting the granularity of batching; Degradation count represents the number of times degradation processing was triggered due to insufficient capabilities of the model service provider; Average model call time represents the average response time for each model call.

[0100] Here's a specific example of EXPLAIN / Profile output. Suppose a user submits a query containing two semantic operators: semantic classification and semantic summarization. The profile output after query execution would look like this: The statistics for the semantic classification operator (PhysicalSemanticProjection) are as follows: 200 input rows, 15 skipped rows (due to empty input columns), 1 batch group (all rows use the same model and prompt word template), 2 model calls (185 rows were batched into 2 requests, subject to the maximum batch size limit), 3 retries, 1 validation failure, 45MB of multimodal data read (video frame data), and an average model call time of 1.2 seconds.

[0101] The statistics for the semantic summarization operator (PhysicalSemanticProjection) are as follows: 200 input lines, 15 skipped lines, 1 batch group, 1 model call (185 lines were combined into 1 request), 5 retries, 2 failed validations, 45MB of multimodal data read (data from the same video frame), and an average model call time of 2.8 seconds.

[0102] From the above profile output, developers can quickly identify that: the total number of model calls is 3 (instead of 400 independent calls in 200 lines), indicating a significant effect of batch processing optimization; the number of retries and verification failures suggests that the output quality of the summarizing operator is slightly lower than that of the classification operator, which may require optimization of the prompt word template for the summarizing operation; and the 45MB of multimodal data read reflects the actual processing scale of the video frame data.

[0103] Compared to traditional solutions, semantic functions in traditional SQL are only displayed as ordinary function call nodes in the EXPLAIN output. They cannot show the number of model calls (developers cannot know how many HTTP requests actually occurred), retries and validation failures (developers cannot perceive quality issues in the model output), or the volume of multimodal data reads (developers cannot assess the overhead of processing large fields). This embodiment elevates semantic operators to first-class operators in the query plan and provides dedicated statistical metrics, making all execution details of semantic computation transparent and visible to developers and operations personnel.

[0104] See Figure 2This document illustrates a preferred embodiment of the present invention, 10. A database semantic query execution plan generation system, comprising: a semantic expression recognition module, used to receive an SQL query statement containing semantic functions or semantic operators and recognize the semantic expressions therein; a semantic operator metadata module, used to generate semantic operator metadata for the semantic expressions, the semantic operator metadata describing the type, input / output specifications, model call configuration, and execution strategy of the semantic operators; a plan rewriting module, used to split the ordinary relational expressions and semantic expressions in the SQL query statement into ordinary relational operators and logical semantic operators, so that ordinary predicate filtering, sampling, window sharding, and limiting the number of returns are executed before the logical semantic operators; and a multimodal delayed reading module, used to handle situations where the logical semantic operators depend on multimodal large characters. When processing segmented data, after the execution of ordinary relational operators, only the multimodal data corresponding to the surviving filtered data rows is read or decoded on demand. The schema compilation and verification module is used to compile the database output type constraints or user-specified structural schemas into model structured output constraints, and perform structured verification on the model's returned results. The data block batch processing module is used during the physical execution phase to merge multiple rows of input within the same data block into a single batch model request based on the semantic operator grouping key, and to split the returned results back into the corresponding original data rows based on the row identifier. The fusion and governance module is used to perform fusion processing when multiple compatible semantic operations exist on the same input data, and to perform degradation processing and output interpretable execution statistics when the capabilities of the model service provider do not meet the requirements.

[0105] It should be noted that the embodiments of the present invention have better implementability and are not intended to limit the present invention in any way. Any person skilled in the art may use the above-disclosed technical content to change or modify it into equivalent effective embodiments. However, any modifications or equivalent changes and modifications made to the above embodiments based on the technical essence of the present invention without departing from the content of the technical solution of the present invention shall still fall within the scope of the technical solution of the present invention.

Claims

1. A method for generating an execution plan for a database semantic query, executed by a database query engine, characterized in that, Includes the following steps: It accepts SQL query statements that contain semantic functions or semantic operators; Identify the semantic expressions in the SQL query statement and generate semantic operator metadata for the semantic expressions. The semantic operator metadata describes the type, input and output specifications, model call configuration, and execution strategy of the semantic operator. The ordinary relational expression and semantic expression in the SQL query statement are split into ordinary relational operators and logical semantic operators, so that the operations of ordinary predicate filtering, sampling, window slicing and limiting the number of returns are executed before the logical semantic operators; When the logical semantic operator depends on multimodal large field data, after the ordinary relational operator is executed, the multimodal data corresponding to the data rows that survive the filtering is read or decoded on demand. Compile database output type constraints or user-specified structural patterns into model structured output constraints; During the physical execution phase, multiple lines of input within the same data block are merged into a single batch model request based on the semantic operator grouping key, and the returned results are split back into the corresponding original data lines based on the line identifier. Perform structured validation on the results returned by the model and output the SQL query results; When the capabilities of the model service provider do not meet the requirements of the semantic operator metadata, the corresponding degradation processing is performed according to the degradation strategy in the semantic operator metadata.

2. The method for generating an execution plan for a database semantic query as described in claim 1, characterized in that, The multimodal large field data includes at least one of binary large objects, video frames, audio clips, and document pages.

3. The method for generating execution plans for database semantic queries as described in claim 1, characterized in that, For video frame input, the target frame is located according to the hierarchical index structure of the video stream, only the frames required by the semantic operator are decoded, and a binary large object array is generated while maintaining the SQL array order.

4. The method for generating an execution plan for a database semantic query as described in claim 1, characterized in that, The database output type constraints are determined by at least one of the following in the database column definition: type declaration, null value constraint, enumeration constraint, and check constraint.

5. The method for generating execution plans for database semantic queries as described in claim 1, characterized in that, When the result returned by the model fails to be verified, a retry repair or abnormal row record operation is performed according to the error handling strategy.

6. The method for generating an execution plan for a database semantic query as described in claim 1, characterized in that, The semantic operator grouping key is determined by the model service provider identifier, model identifier, prompt word template fingerprint, and output mode fingerprint. Multiple lines of input under the same grouping key are merged into one model call.

7. The method for generating execution plans for database semantic queries as described in claim 1, characterized in that, When multiple compatible semantic operations exist on the same input data, the multiple semantic operations are merged into a composite output pattern. Multiple result fields are returned simultaneously through a single model call, and the multiple result fields are split into corresponding SQL output columns or predicate results on the database side.

8. The method for generating execution plans for database semantic queries as described in claim 1, characterized in that, The degradation process, depending on the type of capability that the model service provider does not support, involves either line-by-line calling, plain text output followed by validation, or rejection with an error message.

9. The method for generating an execution plan for a database semantic query as described in claim 1, characterized in that, Also includes: The execution statistics of the semantic operator are displayed in the interpretable output of the query execution plan. These execution statistics include the number of model calls, the number of retries, the number of verification failures, and the amount of multimodal data read.

10. A database semantic query execution plan generation system, characterized in that, include: The semantic expression recognition module is used to receive SQL query statements containing semantic functions or semantic operators and recognize the semantic expressions within them. The semantic operator metadata module is used to generate semantic operator metadata for the semantic expression. The semantic operator metadata describes the type, input and output specifications, model invocation configuration, and execution strategy of the semantic operator. The rewrite module is used to split the ordinary relational expressions and semantic expressions in the SQL query statement into ordinary relational operators and logical semantic operators, so that the operations of ordinary predicate filtering, sampling, window slicing and limiting the number of returns are executed before the logical semantic operators; The multimodal delayed reading module is used to perform on-demand reading or decoding of the multimodal data corresponding to the surviving data rows after the ordinary relational operator has been executed, when the logical semantic operator depends on multimodal large field data. The schema compilation and verification module is used to compile database output type constraints or user-specified structural schemas into model structured output constraints, and to perform structured verification on the results returned by the model. The data block batch processing module is used during the physical execution phase to merge multiple lines of input within the same data block into a single batch model request based on the semantic operator grouping key, and to split the returned results back into the corresponding original data lines based on the line identifier. The fusion and governance module is used to perform fusion processing when there are multiple compatible semantic operations on the same input data, and to perform degradation processing and output interpretable execution statistics when the capabilities of the model service provider do not meet the requirements.

Images