SemPipes: Declarative Tabular ML Pipelines

• SemPipes is a declarative model for tabular ML pipelines that enables developers to specify data transformations in natural language, synthesizing optimized operator code.
• It integrates LLM-powered semantic operators with standard Python DataOps, streamlining tasks like joins, aggregations, and feature engineering.
• It employs evolutionary search and validation at training time to improve predictive performance and reduce pipeline complexity while ensuring execution control.

SemPipes is a declarative programming model for tabular machine learning pipelines that introduces LLM-powered semantic data operators as first-class pipeline components. Its central abstraction is to let a developer specify what a data transformation should accomplish in natural language, while a runtime system determines how to execute that transformation by synthesizing concrete operator implementations from data characteristics, operator instructions, and pipeline context. The design is explicitly aimed at real-world tabular ML settings in which joins, aggregations, cleaning, encoding, feature engineering, augmentation, debugging, missing-value imputation, and multi-table integration dominate engineering effort, and in which unrestricted chat-based code generation is brittle, hard to control, and difficult to optimize systematically (Ovcharenko et al., 4 Feb 2026, Ovcharenko et al., 12 Jun 2026).

1. Conceptual scope and motivation

SemPipes is positioned as a response to a structural limitation in conventional tabular ML tooling. The paper argues that real-world tabular ML is bottlenecked not only by model choice, but by the quality of data operations inside the pipeline. In that setting, standard scikit-learn pipelines are described as too limited because they are linear and single-table oriented, and therefore do not naturally support joins, aggregations, filters, multi-table workflows, or data-dependent feature engineering. SemPipes preserves ordinary Python and skrub DataOps pipeline structure while replacing selected data-centric operations with semantic operators whose implementations are synthesized and optimized at training time (Ovcharenko et al., 4 Feb 2026).

This yields a controlled alternative to end-to-end agentic pipeline generation. Rather than asking an LLM to generate an entire ML system from scratch, SemPipes narrows the synthesis target to specific data operations. The paper explicitly frames this as a declarative paradigm similar in spirit to semantic SQL operators and to frameworks like DSPy, but adapted for tabular ML pipelines. A plausible implication is that the narrower synthesis problem is intended to improve inspectability, reusability, and optimization stability relative to unconstrained chat-based workflows.

SemPipes also separates specification from execution in a precise way. The pipeline author provides intent in natural language; the runtime synthesizes executable code; and the resulting code is then optimized against downstream validation performance. This makes the abstraction declarative without turning the entire pipeline into an opaque prompt artifact (Ovcharenko et al., 4 Feb 2026).

2. Semantic operators and the declarative interface

SemPipes extends Python-based tabular ML pipelines with semantic data operators, or SemOps. These operators have fixed input/output types, are controlled by a natural language instruction $s$, and are executed by a runtime rather than by repeated LLM calls at inference time. The operator set in the paper comprises nine SemOps grouped into feature creation/extraction/augmentation, cleaning and integration, and pipeline parameterization (Ovcharenko et al., 4 Feb 2026).

Category	Operator	Declared behavior
Feature creation / extraction / augmentation	sem_gen_features(D, k, s) \rightarrow D'	Generate $k$ feature columns in $D$
Feature creation / extraction / augmentation	sem_agg_features(D, D_\text{agg}, c_\text{join}, k, s) \rightarrow D'	Generate aggregated features from $D_\text{agg}$ and join to $D$
Feature creation / extraction / augmentation	sem_extract_features(D, C_\text{out}, s) \rightarrow D'	Extract feature columns from data and feature descriptions
Feature creation / extraction / augmentation	sem_augment(D, k, s) \rightarrow D'	Augment $D$ with $k$ rows
Cleaning and integration	sem_fillna(D, c, s) \rightarrow D'	Impute missing values in column $c$
Cleaning and integration	sem_clean(D, c, s) \rightarrow D'	Clean column $c$
Cleaning and integration	sem_refine(D, c, s) \rightarrow D'	Restructure column $c$
Pipeline parameterization	sem_select(D, s) \rightarrow D'	Select subset of columns
Pipeline parameterization	sem_choose(E, s) \rightarrow H	Propose hyperparameters/config for estimator $k$0

The declarative character of SemPipes is localized at the operator level. A developer writes a pipeline in ordinary Python and inserts semantic operators at points where semantic inference is useful. The rest of the pipeline can continue to use standard libraries such as pandas, NumPy, scikit-learn, and compatible estimators such as CatBoost, FT-Transformer, and TabPFNRegressor (Ovcharenko et al., 12 Jun 2026). This is significant because the model does not replace the Python data-science stack; it augments it with natural-language-specified operators for brittle or domain-heavy transformations.

The paper emphasizes that the instruction can encode task semantics, desired transformations, domain knowledge, and output constraints. This suggests that SemPipes treats natural language less as an end-user convenience layer than as a formalizable control surface for data operations.

3. Runtime architecture and training-time synthesis

SemPipes relies on skrub DataOps pipelines as its execution substrate. In this substrate, a pipeline is represented as a computational graph whose nodes are data operations and whose edges are data dependencies. The paper highlights that this graph representation supports lazy execution, pipeline rewriting, multi-table ML workflows, and a unified fit/predict interface. Semantic operators are integrated into this graph as sklearn-style estimators (Ovcharenko et al., 4 Feb 2026, Ovcharenko et al., 12 Jun 2026).

At pipeline fit time, the runtime synthesizes custom implementations for each semantic operator. The synthesis is conditioned on three inputs. The first is input data characteristics, including size, column names, data types, descriptive statistics, values, schema, sample rows, and multimodal content. The second is the natural language instruction supplied by the developer. The third is pipeline context, including the learning task type, the final estimator, the surrounding computational graph, downstream task requirements, model type, dataflow relationships, and input/output schema context (Ovcharenko et al., 4 Feb 2026, Ovcharenko et al., 12 Jun 2026).

This contextualization is central to the SemPipes design. The same operator instruction may induce different implementations depending on whether the task is fraud detection, museum-origin classification, or house-price regression. The paper’s examples reflect this: a sem_fillna operator may synthesize a KNN-based imputer; a date extraction operator may combine flan-t5-small with rule-based parsing; an image feature extractor may use Salesforce/blip-vqa-base; and a refinement operator may use regexes and correspondence dictionaries (Ovcharenko et al., 12 Jun 2026).

After synthesis, execution proceeds locally. The generated code may be CPU-based pandas code, or it may call pretrained local models, including Hugging Face models on a GPU for multimodal extraction. A defining design point is that LLMs are used only during training or synthesis, not during prediction-time serving. The paper therefore describes LLM use as bounded and predictable, with cost scaling with the number of semantic operators rather than with data size (Ovcharenko et al., 4 Feb 2026).

SemPipes validates synthesized implementations beyond syntax. The runtime parses the code, executes it on a sample of the input data, and checks operator-specific output constraints such as expected dataframe shape or required columns. If validation fails, the system retries by feeding the error message back to the LLM. This validation layer is important because SemPipes does not assume that code synthesis alone is sufficiently reliable for pipeline execution (Ovcharenko et al., 4 Feb 2026).

4. Optimization as bi-level search over operator code

SemPipes does not treat synthesized code as fixed. It formulates the pipeline as

$k$1

where $k$2 denotes semantic operators with synthesized state $k$3, $k$4 denotes predictive operators with learnable parameters $k$5, and $k$6 is a scalar utility function. The outer optimization objective is

$k$7

with inner optimization

$k$8

The paper characterizes this as a bi-level optimization strategy: the inner loop fits the downstream model with semantic operator code fixed, and the outer loop mutates operator code to improve validation utility (Ovcharenko et al., 4 Feb 2026).

Because semantic operators are non-differentiable, SemPipes uses tree-structured evolutionary search guided by LLM-based code synthesis. Each node in the search tree corresponds to a candidate version of operator code. Candidate implementations are mutated, inserted back into the pipeline, evaluated on validation data, and recorded with performance and memory traces. The search policy can be Monte Carlo Tree Search, greedy tree search, truncation selection, or random search (Ovcharenko et al., 4 Feb 2026).

The algorithm described in the paper maintains semantic operator states $k$9, memories $D$0, a search tree $D$1, and per-step utility values $D$2. For each semantic operator in computational DAG order, the optimizer summarizes pipeline context, extracts prior utilities and memories along the search path, partially fits the pipeline up to that operator, and invokes a type-specific evolve(...) function. The memory trace stores attempted versions, reasoning, scores, and code-comment rationales (Ovcharenko et al., 4 Feb 2026). This suggests that optimization is not merely black-box mutation; it is reflective search conditioned on pipeline state and prior failures.

The demo paper describes the same mechanism more operationally: candidate operator implementations are mutated, the full pipeline is evaluated on validation data, and downstream predictive performance serves as the fitness function. The optimizer uses tree-structured search, candidate code variants, reflective prompting, prior performance scores, and a tree-structured memory (Ovcharenko et al., 12 Jun 2026).

5. Empirical results and comparative position

The main SemPipes evaluation covers 19 pipelines across 5 tabular ML task families: clinically informed feature extraction, blocking for entity resolution, feature engineering on relational data, data annotation for model debugging, and data augmentation for fairness. Comparisons include hand-written expert pipelines, agent-generated pipelines from AIDE and mini-SWE-Agent, and specialized baselines such as CAAFE for feature generation, a prompting baseline for missing value imputation, and Palimpzest and LOTUS for multimodal extraction. The main experiments use Google Gemini 2.5 Flash, with temperature $D$3 for non-optimized execution and temperature $D$4 for optimization; non-optimized pipelines allow up to 5 retries if code fails, optimized pipelines use 24 optimization iterations, and each run is repeated five times (Ovcharenko et al., 4 Feb 2026).

The headline empirical pattern is that semantic operators improve both expert-written and agent-generated pipelines. The paper reports that 17/19 cases improved when adding semantic operators and instructions even before optimization, 18/19 improved after optimizing the semantic operators, and 17/19 improved over the non-optimized semantic-operator version. The authors emphasize that these gains come from improving data operations rather than from changing models or hyperparameters (Ovcharenko et al., 4 Feb 2026).

Representative task-level results are concrete. In Scrabble rating feature engineering, optimized semantic operators improved RMSE by 18%–26%. In the SIGMOD entity resolution blocking setting, SemPipes replaced hundreds of lines of hand-written feature extraction and blocking code and improved the Rutgers solution from 5th to 3rd place on the public leaderboard, according to the paper’s claim. In HiBug data annotation, optimizing the semantic operator improved annotation accuracy by more than 16% (Ovcharenko et al., 4 Feb 2026).

The paper also reports simplification of expert-written pipelines. Examples include $D$5 LoC for micromodels, $D$6 LoC for the Rutgers blocking pipeline, $D$7 LoC for the sustech blocking pipeline, $D$8 DF ops for kaggle-house-b, and $D$9 LoC for hibug. This is important because SemPipes is presented not only as an accuracy-improvement mechanism but also as a way to compress brittle manual data logic into higher-level operator specifications (Ovcharenko et al., 4 Feb 2026).

Against specialized approaches, the paper reports that on three datasets CAAFE provides modest gains, whereas SemPipes achieves larger gains overall: RF improved by 10.6% with SemPipes versus 4.2% with CAAFE, and TabPFN improved by 4.4% with SemPipes versus negligible improvement with CAAFE. For missing value imputation, SemPipes outperforms the prompting baseline from Narayan et al. by +6.3% on Restaurant and +1.6% on Buy. For multimodal feature extraction, the paper states that SemPipes code synthesis is often more cost-efficient and can outperform or match Palimpzest and LOTUS depending on modality; for text, direct per-item LLM processing may be slightly more accurate, but SemPipes is much cheaper and scales better (Ovcharenko et al., 4 Feb 2026).

The optimization study over five classification pipelines further reports that all tested LLMs improve performance, most gains occur within 5–8 search steps, MCTS performs best overall, and Qwen-Coder-2.5 is surprisingly competitive despite being much smaller than GPT-4.1 and Gemini-2.5-Flash (Ovcharenko et al., 4 Feb 2026).

6. SemPiper, usage scenarios, and limitations

SemPiper is the interactive demo and interface for SemPipes rather than the programming model itself. It exposes the pipeline graph, synthesized operator code, and evolutionary optimization process. The interface includes at least two main tabs, Pipeline and Optimizer. In the Pipeline tab, one can load a provided pipeline or implement a new one using arbitrary Python libraries, select an LLM and temperature, execute the pipeline, inspect the computational graph, inspect each semantic operator, view synthesized code, inspect intermediate data, and observe model performance, runtime, and cost. In the Optimizer tab, one can inspect evolutionarily generated pipeline variants, validation performance, evolved operator code, and the optimization trajectory over iterations, including a search tree of mutated implementations and their scores (Ovcharenko et al., 12 Jun 2026).

The demonstration uses three end-to-end scenarios. In fraud detection on multi-table retail data, the pipeline joins baskets and products tables, applies text normalization and statistics, uses sem_fillna, sem_extract_features, sem_gen_features, and sem_agg_features, and trains a CatBoost classifier. In cultural origin prediction for museum data, the pipeline combines an artworks table with free-text descriptions, extracts NLP features with spaCy, uses semantic operators including sem_extract_features, sem_gen_features, and sem_refine, and trains an FT-Transformer classifier. In house-price prediction on multimodal real-estate data, the pipeline joins facts, cities, and images, vectorizes with TableVectorizer, trains TabPFNRegressor, analyzes outputs with DuckDB, and uses semantic operators such as sem_clean, sem_extract_features, and sem_gen_features (Ovcharenko et al., 12 Jun 2026).

Several misconceptions are explicitly ruled out by the papers. SemPipes is not an end-to-end AutoML or agentic pipeline generator; it improves selected data operations inside a broader pipeline. It does not use LLM calls during inference. It does not yet support time series or videos. The authors also note security risks, stating that synthesized code must be run in a hardened sandbox. Additional limitations include a narrow current operator set, an optimization objective that currently focuses on predictive performance rather than joint runtime or cost, dependence of synthesis quality on the LLM and prompt/context quality, increased computation, time, and cost due to search, and reliance on well-structured integration around DataOps/skrub-style pipeline graphs (Ovcharenko et al., 4 Feb 2026, Ovcharenko et al., 12 Jun 2026).

Taken together, these papers define SemPipes as a controlled synthesis architecture for data operations rather than a generic conversational coding assistant. Its core claim is that selected semantic transformations in tabular and multimodal ML pipelines can be specified declaratively, compiled into executable operator code at training time, and then optimized against downstream utility in a way that improves predictive performance and often reduces pipeline complexity (Ovcharenko et al., 4 Feb 2026, Ovcharenko et al., 12 Jun 2026).