Testing NVIDIA's Structured Data Models: Zero-Training Predictions Work, But Three Default Settings Fail Silently
MarkTechPost consulting intern Sana Hassan tested NVIDIA's Structured Data Models library on CPU, finding that its pretrained tabular models match scikit-learn trained baselines on benchmarks like breast cancer classification without any training. However, three default settings silently corrupt results: the default preprocessing recipe drops timestamp and text columns, the explainer reports only the last estimator, and the relational model reads future data to produce inflated scores when no time column is declared.
Sana Hassan published a hands-on tutorial on MarkTechPost systematically testing NVIDIA's newly released Structured Data Models library. The library wraps several pretrained tabular foundation models behind a single PyTorch interface: the user provides labeled context rows and unlabeled query rows, and the model returns probabilities or a full predictive distribution in one forward pass, with no training step and no hyperparameters to tune. On the breast cancer dataset, using 300 labeled rows as context, both TabICLv2 and KumoTabular reached 0.970 accuracy with AUCs of 0.996 and 0.995 respectively, without any training, matching logistic regression and gradient boosting baselines fitted on the same 300 rows. On the diabetes regression task, the model's median prediction achieved an RMSE of 53.6, slightly better than RidgeCV at 54.3 and clearly better than gradient boosting at 64.7, while a single forward pass simultaneously returned 999 quantiles forming a full predictive distribution whose 80% and 90% intervals covered close to 81% and 91.5% of held-out targets, showing good calibration. These results explain why practitioners would want to reach for this library directly.
But Hassan's real message is not about the models themselves—it is about the defaults. He found three places where the library quietly does the wrong thing without raising an error. The first is the preprocessing recipe: TabICLv2's default recipe dispatches on semantic type with branches only for categorical and numerical columns, so timestamp and text columns never become features. On a support-ticket escalation prediction task—where the escalation signal comes from when tickets were opened and keywords in the ticket text—the default recipe scored an AUC of only 0.525, close to chance. The library does emit a RuntimeWarning naming the ignored column types, but it is a warn-once: it fires the first time and is suppressed for the rest of the process, so every later model call in the same notebook or service drops those columns in silence. Prepending AddCalendarFields to convert timestamps into cyclic hour and weekday features lifted the AUC to 0.634; adding TFIDF to extract terms from the comment text lifted it further to 0.789.
The second trap is in the explainer. GradientExplainer calls the output function once per estimator, and each call overwrites the previous result, so with num_estimators=4 the explanation you receive is only the last estimator's, not their average. More subtly, the default recipe shuffles class labels per estimator, so if you select the target probability by column position rather than by column name, the sign of every feature flips on seeds where the order is reversed. Hassan verified this across six seeds: position-based selection flipped all signs on two seeds, while name-based selection gave the correct direction on all six.
The third and most serious trap involves the relational model. Hassan constructed a small shop database with 800 customers, 60 products, and a year of orders, asking whether each customer would order again within 30 days of a cutoff. KumoRelational, with the time column declared, reads order rows directly from the three raw tables via foreign-key traversal and reaches an AUC of 0.823—nearly identical to a TabICLv2 pipeline built on six hand-engineered history features (orders and spend in the last 30 and 90 days, days since last order, lifetime order count) which reaches 0.828. But when he does not declare the time column, the AUC jumps to 0.940. The reason is simple: without a time column, the sampler is free to return orders placed after the cutoff, which are exactly the orders that define the label. The model is no longer predicting; it is reading the answer. Nothing errors, and the number looks like a breakthrough.
Hassan's conclusion is that the defaults deserve more scrutiny than the models. Zero-training tabular predictions genuinely work, but every component with default behavior can silently block critical information from reaching the model—or let information that should not be visible leak in. His advice boils down to three habits: declare semantic types deliberately rather than relying on inference, select classes by name rather than position inside an explainer, and put every table with a time column into the time_columns parameter. The core principle: check what reaches the model before trusting what comes out of it.
All figures above come from Hassan's single CPU run on synthetic or small benchmark datasets. The author is a consulting intern at MarkTechPost and a dual-degree student at IIT Madras. These results do not constitute independent replication, nor do they represent the library's performance on large-scale production data.