PaperlayerView exact revision on arXiv

Source-linked AI summary

Test-Time Compute for Tabular Foundation Models: Mechanisms, Gains, and Limits

Kanghui Ning, Marin Biloš, James T. Wilson, Yilang Zhang, Kashif Rasul, Dongjin Song, Anderson Schneider, Yuriy Nevmyvaka

arXiv:2610.12005v1cs.LG

TL;DR

As pretrained tabular foundation models become more capable, the gains from additional task-specific computation remain poorly understood. This paper compares adaptation, aggregation, and context construction across modern models and benchmark settings. It finds gains from compact adaptation and selective aggregation, while context-selection benefits depend on the data and combining interventions costs more computation.

  • Problem

    As tabular foundation models grow increasingly capable out of the box, how much additional task-specific computation improves their predictions remains poorly understood.

    Source: §1 · p. 1

  • Method

    The study separates task-specific computation into adaptation, aggregation, and context construction, evaluating adaptation across three backbones and the other two axes in depth on TabPFN-3.

    Source: §1 · p. 2

  • Results

    DiagScale captures much of fine-tuning’s gains across three backbones; selective aggregation adds gains on TabPFN-3, while context-selection outcomes vary and tested expansion methods show no consistent benefit.

    Source: §1 · p. 2, §9 · p. 9

  • Takeaways & Limitations

    Combining DiagScale and configuration aggregation improves over either intervention alone on TabPFN-3, but costs substantially more measured computation than DiagScale alone.

    Source: §1 · p. 2

    Predicting per-dataset error reductions remains difficult: tested predictors achieve at best cross-validated R2 of 0.012, leaving recipe choice for new datasets open.

    Source: §8 · p. 9, §9 · p. 10

Abstract

from arXiv · show

Which forms of test-time compute improve the predictions of strong pretrained tabular foundation models (TFMs)? We systematically study this along three axes: adaptation, aggregation, and context construction. Our evaluation spans modern TFMs across the TabArena benchmark, supplemented by experiments on wide and large-scale tables from OpenML. For adaptation, we introduce DiagScale, a diagonal query-key similarity update. It trains only 0.003-0.03% of model parameters and achieves gains comparable to full fine-tuning across three independently pretrained backbones. For aggregation, both pool composition and selection strategy matter. TabPFN-3 already averages predictions from different preprocessing variants of the same data, and adding more such predictions yields diminishing returns. With a broader pool of 96 configurations, greedy selection reduces error by 2.4% relative to the default predictor, but uniform averaging increases error. For context construction, attention-guided retrieval improves TabPFN-3's predictions on some large tables and supports source pools beyond the full context memory limit. The context expansion methods we test yield no consistent improvement. Taken together, our results suggest that adaptation and selective aggregation yield consistent benchmark-level gains. The benefits of context construction depend more on the task and data regime. Adaptation and aggregation over the same backbone yield further gains when combined, but require substantially more computation than default inference. These trade-offs motivate choosing strategies according to the available computation budget. Code is available at https://github.com/kanghui-learning/test-time-compute-for-tabular-foundation-models.

1 INTRODUCTION

The introduction asks how much additional task-specific computation improves increasingly capable tabular foundation models, and separates contributions from adaptation, aggregation, and context construction. It previews compact adaptation gains, selective aggregation gains, context-dependent outcomes, and further gains from combining interventions.

1 INTRODUCTION

  • Task-specific training and inference can combine context selection with parameter updates, making it important to examine each operation’s contribution separately.Prior work such as LoCalPFN combines local retrieval with fine-tuning (Thomas et al., 2024).Source: §1 · p. 1
  • As tabular foundation models grow more capable out of the box, the benefits of additional test-time computation remain poorly understood.The paper distinguishes adaptation, aggregation, and context construction and examines individual interventions as well as their combinations.Source: §1 · pp. 1–2
  • Training 0.003–0.03% of parameters, DiagScale achieves gains close to full fine-tuning across TabPFN-3, TabICL v2, and TabFM.It learns diagonal multipliers in attention modules while freezing pretrained weights.Source: §1 · p. 2
  • Greedy selection from 96 configurations gains 67 Elo, whereas uniform averaging over the same predictions degrades performance.Adding more native TabPFN-3 ensemble predictions yields diminishing returns, and restricting selector access to training-side labels substantially reduces the larger pool’s advantage.Source: §1 · p. 2
  • Attention-guided row selection can improve or degrade performance relative to random selection, while tested context-expansion methods show no consistent improvement.Column-selection benefits also vary across datasets.Source: §1 · p. 2
  • +93 Elo on TabPFN-3 comes from combining DiagScale with configuration aggregation, exceeding either intervention alone but costing 253 GPU-hours.The reported workloads cost 6.6 GPU-hours for DiagScale and 248 for aggregation.Source: §1 · p. 2

2 RELATED WORK

Prior work establishes pretrained tabular foundation models as competitive learners and explores task-specific optimization, retrieval, and ensembling. This paper situates its study among these approaches to additional task-specific computation.

Tabular foundation models

Task-specific learning and inference

Ensembling

  • TabPFN averages predictions across preprocessing choices and permutations, while greedy ensemble selection combines selected model-library members (Ye et al., 2025).Tuning and ensembling are components of AutoGluon and TabArena (Erickson et al., 2020; 2025).Source: §2 · pp. 2–3

Test-time compute

3 A FACTORIZED VIEW OF TEST-TIME COMPUTE

The paper factorizes test-time computation by the inference-pipeline component it modifies: parameters, member predictions and their reduction, or conditioning data. This framework supports controlled comparisons of individual interventions and combinations.

3 A FACTORIZED VIEW OF TEST-TIME COMPUTE

  • Three test-time-compute families modify different pipeline components: adaptation changes model parameters, aggregation changes the prediction pool and its reduction, and context construction changes conditioning data.The pipeline also includes preprocessing, a frozen tabular foundation model, and combination of predictions across data views.Source: §3 · p. 3, Figure 1 · p. 3
  • For labeled training data D and query x, the factorized inference pipeline represents predictions through model state θ_m, context constructor g_m, and reducer R_w.θ_m is pretrained or adapted; g_m constructs conditioning rows, columns, and representation; R_w combines M member predictions.Source: §3 · p. 3
  • Adaptation changes θ_m, and restricting updated parameters controls the task-specific correction family and the information needed to estimate it.The study compares parameter subsets and tests whether similarity-only correction can provide useful gains.Source: §3 · p. 3
  • Aggregation changes member predictions and their reduction; pool quality and error complementarity interact with the reducer and its validation data.Uniform averaging uses fixed weights, whereas selecting members or learning weights requires validation data.Source: §3 · p. 3
  • Context construction changes g_m through selection of existing rows or columns, or expansion with synthetic rows, columns, or labels.Curation and retrieval can emphasize relevant evidence or satisfy capacity constraints; expansion tests whether added context improves in-context learning.Source: §3 · pp. 3–4

4 EVALUATION DESIGN

Adaptation is evaluated across three pretrained tabular foundation models, while aggregation and context construction are studied on TabPFN-3. The evaluation combines TabArena with additional wide-table and large-row OpenML experiments.

4 EVALUATION DESIGN

  • TabArena evaluation covers 51 classification and regression datasets, ranging from 748 to 150,000 rows across ten domains.Adaptation is studied on TabPFN-3, TabICL v2, and TabFM; aggregation and context construction are studied on TabPFN-3.Source: §4 · p. 4
  • Additional wide-table and large-row studies use OpenML datasets evaluated with specified splits and reference models.The TabArena evaluation follows its official protocol.Source: §4 · p. 4
  • Elo ratings compare methods through wins, ties, and losses against 68 fixed reference entries; ΔElo compares each candidate with its baseline within the same fit.The evaluation also reports TabArena normalized score and percentage error changes relative to baseline.Source: §4 · p. 4

5 ADAPTATION: A COMPACT SIMILARITY UPDATE

The section narrows adaptation to query–key similarity, motivated by a sweep in which SoftScale approaches full fine-tuning. DiagScale then achieves gains close to full fine-tuning across three backbones while training a small fraction of their parameters.

Adaptation sweep

  • SoftScale reaches +26 Elo with 1.03M parameters, close to full fine-tuning at +25 with 58.3M parameters.Their normalized scores are 0.703 and 0.704, respectively.Source: §5 · p. 4, Table 1 · p. 4

What SoftScale fine-tuning changes

  • Fine-tuning the context-size branch s alone recovers 93–106% of the gain from jointly fine-tuning both SoftScale branches, versus 8–16% for the query-dependent gate g.The diagnostic compared the branches separately on three datasets.Source: §5 · p. 4

DiagScale

  • DiagScale learns dimension-specific query multipliers directly, freezing pretrained weights and changing attention logits through query–key similarity.The observed SoftScale changes primarily alter relative scaling across dimensions rather than uniformly rescaling vectors.Source: §5 · p. 5

Cross-backbone results

  • DiagScale achieves gains close to full fine-tuning across all three backbones while training 0.003%–0.03% of parameters.Per-dataset error reductions are correlated with full fine-tuning’s (ρ = 0.69–0.89).Source: Table 2 · p. 5, §5 · p. 5, Figure 2 · p. 5

6 AGGREGATION: CONFIGURATION BREADTH AND SELECTIVE REDUCTION

TabPFN-3 already aggregates multiple native views, so the section tests whether more views or broader configuration pools help, and how the reducer affects results. More views yield diminishing returns, while configuration-pool outcomes depend on selection strategy and available validation data.

Aggregation across configurations

  • Greedy selection from 96 configurations reduces error by 2.44% relative to the default, while uniform averaging increases it by 3.68%.Best-single yields −1.25% with a confidence interval that includes zero; greedy selection yields +67 Elo.Source: Figure 3 · p. 6, §6 · p. 6

Native-view scaling

  • Increasing native views beyond V = 8 yields diminishing returns: V = 16 reduces error by 0.48%, V = 32 by 0.60%, and V = 64 shows no clear improvement over V = 32.V = 32 also yields +21 Elo relative to the default.Source: §6 · p. 6, Figure 3 · p. 6

Aggregation across configurations

  • With larger configuration subsets, average error decreases for all three reducers, but uniform averaging remains worse than the default; greedy performs best at K = 96.Best-single’s point estimate is better than the default from K = 16 onward.Source: §6 · p. 6, Figure 3 · p. 6

Dependence on validation data

  • Using all validation examples reduces error by 2.4%, whereas using one eighth yields an estimated error 0.4% above the default.Greedy aggregation’s gains depend on both the configuration pool and the validation data available for selection.Source: §6 · p. 7

7 CONTEXT CONSTRUCTION: CURATION AND EXPANSION

Context construction tests row and column curation as well as context expansion. Attention-guided retrieval helps on some larger tables and can use pools beyond the full-context memory limit, but results vary by dataset; tested expansion methods show no consistent gains.

Column curation

  • Across seven wide tables, selection reduces error by 30–67% on genomics, mass-spectrometry, and text datasets, but slightly increases it on three of four molecular or image datasets.With 500 columns fixed across all eight views, importance-based selection reduces error by 66% relative to random selection on amazon-reviews.Source: §7 · p. 7

Attention-guided row selection

  • Retrieval lowers log loss on four of five larger tables where full context fits, and reduces it by 3.5% on Higgs with a 10M-row pool and 5.2% on US_Accidents with a 7.68M-row pool.The latter comparisons cost 3.9 and 2.1 times full-context inference, respectively; blockwise retrieval supports pools up to 10M rows beyond the 4M-row fit limit.Source: §7 · p. 8
  • Attention-selected contexts reduce log loss versus matched random contexts by 65% on Covertype, 91% on Poker, and 3–4% on Higgs at two source-pool sizes.Attention-selected contexts outperform the full-context baseline in all four settings, while matched random contexts perform worse.Source: §7 · p. 8
  • The benefits of row selection vary with data characteristics: on COMET_MC, attention-guided selection raises log loss from 0.0151 with full context to 0.2302.Replacing selected rows with matched random samples brings log loss back to 0.0158; class-proportion adjustment also fails to resolve the degradation.Source: §7 · p. 8

Context expansion

  • Tested context-expansion methods, including constructed rows and features and learned row additions, yield no consistent improvements across evaluated datasets.The constructions produce occasional improvements, but no reliable gains over the original context.Source: §7 · p. 8

8 COMPOSITION, COST, AND VARIATION ACROSS TASKS

Combining DiagScale with configuration aggregation improves over either intervention alone on TabPFN-3, but the added gain comes with substantial computation. Per-dataset gains are uneven, and the tested predictors estimate their magnitude with limited accuracy.

Composition

  • The DiagScale-plus-greedy-aggregation recipe gains 93 Elo over the published default and reduces error by 2.35% versus DiagScale alone and 0.64% versus aggregation alone.It combines DiagScale adaptation with greedy aggregation across 96 configurations.Source: §8 · p. 8, Figure 5 · p. 9

Performance and cost

  • The combined recipe gains 93 Elo at 253.1 GPU-hours, versus 26 Elo at 6.61 GPU-hours for DiagScale and 67 Elo at 247.5 GPU-hours for aggregation.The combination costs 2.3% more than aggregation alone; increasing native views to 32 gains 21 Elo at 1.66 GPU-hours.Source: Figure 5 · p. 9, §8 · p. 9
  • Frozen TabFM achieves higher Elo than TabPFN-3 with DiagScale and aggregation at a lower total cost: 19.3 versus 253.1 GPU-hours.The evaluated recipes spend computation differently: adaptation mainly on fitting, and configuration aggregation mainly on generating out-of-fold predictions.Source: §8 · p. 9

Variation and predictability of gains

  • The five largest positive per-dataset reductions account for 46–70% of their sum, while tested predictors achieve at best a cross-validated R2 of 0.012 for predicting reduction magnitudes.This indicates limited accuracy in anticipating gains for a new dataset using the tested predictors.Source: §8 · p. 9

9 DISCUSSION AND CONCLUSION

The paper separates test-time computation into adaptation, aggregation, and context construction, finding that selective adaptation and aggregation can improve benchmark results while context benefits vary. It leaves recipe selection for unseen datasets unresolved.

9 DISCUSSION AND CONCLUSION

  • DiagScale captures much of the fine-tuning gain across three backbones, and selective aggregation adds gains on TabPFN-3.The combined interventions improve over either alone, while context selection helps on some datasets and tested expansion methods show no consistent benefit.Source: §9 · p. 9
  • The same pool of configurations produces different outcomes under greedy selection and uniform averaging, while row-selection controls can improve or degrade predictions.These comparisons help separate the contribution of individual operations from full-pipeline performance.Source: §9 · p. 9
  • Choosing a test-time compute recipe for a new dataset remains open: aggregate benchmark gains do not reliably predict benefits on unseen datasets.The tested predictors provide limited guidance at the dataset level.Source: §9 · p. 10

AI USE STATEMENT

The paper reports its AI-assisted work and implementation choices, describes a TabFM reproduction, and specifies the benchmark and external-table evaluation coverage.

AI USE STATEMENT

  • The authors used generative AI to assist with text, related-work discovery, and software, and reviewed the assisted work while taking responsibility for the final content.Source: AI USE STATEMENT · p. 11

A.1 BACKBONES AND MODEL IMPLEMENTATIONS

  • Experiments use TabPFN-3, TabICL v2, and TabFM, with adaptation forks for TabICL and TabFM and specified hardware, precision, and package details.TabPFN-3 is the primary backbone; the TabFM reproduction uses PyTorch on one H100 rather than the reference JAX/TPU setup, with additional settings differing on three datasets.Source: §A.1 · p. 14, §A.2 · p. 14

A.2 TABFM REPRODUCTION

  • Across 51 TabArena datasets, the TabFM H100 reproduction has a median absolute relative task-error difference of 0.22% from the TPU/JAX reference, and matches or improves on 34.It is compared against released per-dataset reference numbers because TabFM was released after the TabArena snapshot and has no official leaderboard entry.Source: §A.2 · p. 14, Table 3 · p. 14

A.3 DATASETS, SPLITS, AND EVALUATION COVERAGE

  • TabArena covers 51 curated datasets evaluated with three-fold cross-validation, while external row-curation studies use five seed-specific OpenML partitions and separate task-error metrics.TabArena’s full protocol has 816 dataset–repeat–fold cells; the external partitions are study-specific rather than published OpenML task splits.Source: §A.3 · pp. 15–16

A.4 METRICS AND REFERENCE MODELS

The appendices specify scoring and reference procedures, adaptation and validation settings, and learning-rate selection. They report adaptation results across backbones, including dataset-level variation and validation fallbacks.

A.4 METRICS AND REFERENCE MODELS

  • Task errors use 1 − AUC, log loss, or RMSE; Elo compares methods by cell-level wins and fits ratings jointly, while normalized scores rescale dataset performance to [0, 1].The paired benchmark summary averages log error ratios within datasets and weights datasets equally; negative values indicate improvement, and its bootstrap intervals condition on selected recipes.Source: §A.4 · p. 16
  • Elo comparisons use 68 fixed reference entries, including the frozen TabFM reproduction, and compare each candidate with a published default or frozen TabFM baseline.Task-specific choices use training-split validation or out-of-fold predictions, but study-level learning rates use aggregate test performance on the reporting benchmark; Table 4 describes external OpenML row-curation tables and their evaluated pools.Source: §A.4 · p. 17, Table 5 · p. 17, Table 4 · p. 17

B.1 ADAPTATION METHODS AND PARAMETERIZATIONS

  • DiagScale adapts query–key similarity with a diagonal multiplier while freezing pretrained weights; the adaptation sweep also tests full fine-tuning, selective module updates, and LoRA.Its trainable parameter counts vary by backbone and task type, and are compared with complete checkpoint counts in Table 6.Source: §B.1 · pp. 18–19, Table 6 · p. 19

B.2 TRAINING AND MODEL-SELECTION PROTOCOL

  • Adaptation fits on task training data for at most 30 epochs, selects checkpoints on validation data, and returns pretrained weights when no epoch improves validation performance.Fine-tuning and checkpoint validation use two views; deployment uses each backbone’s default view count.Source: §B.2 · p. 19

B.3 LEARNING-RATE SELECTION AND SENSITIVITY

  • Across the tested learning-rate grids, DiagScale’s ∆Elo varies less than full fine-tuning on TabPFN-3 and TabICL v2, and both methods retain positive ∆Elo in every partition.TabPFN-3 DiagScale falls below the default at its largest tested rate; the figure compares five rates on the same 51 datasets, and Table 7 reports global and five-fold selections.Source: §B.3 · pp. 19–20, Figure 6 · p. 20, Table 7 · p. 20

B.4 COMPLETE CROSS-BACKBONE RESULTS

  • On TabFM, DiagScale lowers mean relative error by 0.29% but slightly increases median error (+0.01%), improving 25 of 51 datasets.Dataset size has only weak correlations with improvement (ρ = −0.15 to +0.26).Source: §B.4 · p. 22
  • Validation selects pretrained weights in 297/252 full-FT/DiagScale evaluations on TabPFN-3, 225/211 on TabICL v2, and 196/173 on TabFM.The direct DiagScale-versus-full-fine-tuning paired error intervals are conditional on the selected learning rates and recipes and do not establish statistical equivalence.Source: §B.4 · pp. 21–22, Table 9 · p. 22

B.5 MECHANISM DIAGNOSTICS AND ABLATIONS

Mechanism diagnostics find that context-length scaling recovers far more of SoftScale’s joint-training gain than its query-dependent gate, while DiagScale ablations test how much restricted updates retain. The following aggregation setup builds a pool of native TabPFN-3 configurations and selects among their predictions using training-side validation.

B.5 MECHANISM DIAGNOSTICS AND ABLATIONS

  • Training the context-size branch alone recovers 92.8–106.2% of joint SoftScale gain, versus 8.1–16.0% for the query-dependent gate.Both branches are trained separately from the pretrained model with other parameters frozen; values above 100% mean the restricted run outperforms joint training on that split.Source: §B.5 · p. 23, Table 11 · p. 23
  • Across module groups, the learned scale change is dominated by reorientation rather than a uniform temperature adjustment, with a magnitude index of 0.018–0.241.The index rescales the ∥∆b∥-weighted alignment between the random-direction baseline and one.Source: §B.5 · p. 23
  • Matched-norm random perturbations to pretrained feature-embedder weights retain 13.2–54.0% of the gain, while perturbing trained weights leaves 98.0–100.6% intact.Reverting pretrained weights gives similar retention (8.5–56.6%); other trained modules contribute in both controls.Source: §B.5 · p. 23
  • Training DiagScale’s δ across all scaling modules recovers 96.3–137.1% of joint SoftScale loss reduction; restricting it to three feature-embedder modules (384 parameters) recovers 74.9–82.5%.Both comparisons use learning rate 10^-2 and each experiment’s joint SoftScale baseline.Source: §B.5 · p. 23

C.1 CONFIGURATION-POOL CONSTRUCTION

  • The 96-member pool uses TabPFN-3-native preprocessing and inference settings from TabArena’s tuned TabPFN-v2.5 search space, excluding its v2.5-specific entry.The pool varies settings such as softmax temperature, probability balancing, scaling, categorical handling, and target preprocessing.Source: §C.1 · p. 24
  • Each configuration is tested with eight native views, so the complete pool uses 768 test-side view evaluations versus 32 for one configuration at 32 views; the settings are not compute-matched.Validation uses two native views per member.Source: §C.1 · p. 24

C.2 REDUCERS AND VALIDATION PROTOCOL

  • Greedy selection repeatedly adds the member minimizing updated out-of-fold loss, with replacement, for 40 rounds; a member’s weight is its selection count divided by 40.Out-of-fold predictions use other folds as context, and selection uses log loss for classification or RMSE for regression.Source: §C.2 · pp. 24–25

C.3 AGGREGATION RESULTS

Aggregation gains depend on both pool size and reducer: native-view improvements plateau, while greedy selection benefits from broader configuration pools. Reduced access to validation labels weakens those gains, and context-construction results vary across datasets and memory regimes.

C.3 AGGREGATION RESULTS

  • At V = 32, 48, and 64, native-view error changes are −0.60%, −0.52%, and −0.51%; greedy selection over 96 configurations yields +67 Elo against the default.A randomly sampled configuration increases error by 11.35% on average (95% CI: [5.07%, 19.69%]); the full pool’s mean greedy point estimate improves through K = 96.Source: Table 12 · p. 26, §C.3 · p. 26
  • On the same K = 96 predictions, greedy selection lowers error by 1.20% [0.57%, 2.03%] relative to best-single and is better on 42 of 51 datasets.Table 13 summarizes the three reducers by task type.Source: §C.3 · p. 26

C.4 DEPENDENCE ON VALIDATION DATA

  • With only one eighth of selector labels, point estimates remain above the default for every evaluated pool size, although larger pools improve point estimates at every label budget.Member predictions and configuration subsets are fixed across budgets, so differences reflect selector access to validation labels.Source: §C.4 · pp. 26–27, Table 14 · p. 27

D.1 SHARED SETUP AND TERMINOLOGY

  • The shared context setup keeps backbones frozen; model-aware row retrieval uses attention-guided contexts, while expansion is compared with the same context without added rows or columns.Large-row studies use single-view inference and compare with feed-all at the same source-pool size within memory, or at 4M rows beyond capacity.Source: §D.1 · pp. 27–28

D.2 ROW CURATION AND RETRIEVAL

  • On Higgs, mean log loss decreases through 10M rows under the same splitting rule with no truncation, while the capped control rises after 6M; query partitions also change, so this comparison does not isolate truncation.At 4M rows, two-block scoring increases retrieval log loss versus unsharded scoring by 0.01% on Higgs, 0.68% on US_Accidents, and 57.1% on COMET_MC, averaged over five paired seeds.Source: §D.2 · p. 28
  • Across 15 benchmark datasets, corrected intervals exclude zero for four under the eight-view default—two positive and two negative—and resolved single- and eight-view signs agree.Retained attention mass ranges from 100% on blood-transfusion to 14% on diamonds.Source: §D.2 · p. 31

D.3 MATCHED-ROW CONTROLS AND THE COMET FAILURE

This section examines retrieval controls and the predictability and cost of test-time interventions, covering row identity, setting-dependent column-selection and context-expansion gains, combined DiagScale and aggregation, and aggregation runtime.

D.3 MATCHED-ROW CONTROLS AND THE COMET FAILURE

  • Across four settings, attention-selected rows outperform matched random identities, while random selection is worse than feed-all under fixed clusters, context sizes, and refits.On COMET_MC, random selection brings log loss within 5% of feed-all, while retrieved contexts have a 40.3% median rare-class share versus 1.7% in the source pool. The median total-variation shift is 0.386 and correlates with per-cluster error (Spearman +0.81); class-marginal repair lowers mean log loss from 0.2302 to 0.1270 but AUC falls to 0.569.Source: §D.3 · pp. 32–33

D.4 COLUMN CURATION

  • Column-selection gains were mixed: smaller contexts increased gains on Bioresponse, hiva_agnostic, and QSAR-TID-11, but CIFAR_10 changed little and trends were nonmonotonic in D/n.In the unstratified sweep, Bioresponse’s mean error reduction at n = 100 changed from 9.20% to −2.66%; hiva_agnostic contexts omitted at least one test-set class in three of four seeds at n = 50, two at n = 100, and one at n = 200.Source: §D.4 · p. 35

D.5 CONTEXT EXPANSION

  • 10 of 171 learned-row cases met the effect-and-consistency criterion, although 54 of 171 showed any improvement.At M = 32, 128, and 512, median reductions were −0.03%, −0.13%, and −0.12%; 7 of 72, 2 of 69, and 1 of 30 cases met the criterion, respectively. On concrete at M = 32, optimization lowered error by 0.684% while initialization raised it by 0.063%, a 0.747 percentage-point optimization benefit.Source: §D.5 · pp. 36, 39, Table 24 · p. 36

E.1 COMPOSITION OF INTERVENTIONS

  • −2.352% [−4.557%, −0.742%] relative to DiagScale and −0.643% [−0.973%, −0.353%] relative to aggregation were the composition’s error changes; it improved over both on 27 of 51 datasets.The composition lowered mean log error by 0.031226; its interaction was +0.000968 [−0.002323, +0.003923], an interval that does not establish equivalence to zero.Source: §E.1 · p. 40

E.2 CONCENTRATION OF GAINS

  • The ratio-of-means estimator yields 41 aggregation wins, versus 42 under the mean-log-ratio estimator; Table 27 summarizes concentration of positive per-dataset error reductions.The analysis uses the seven deployed outcomes, including validation-selected fallback for adaptation.Source: §E.2 · p. 40, Table 27 · p. 40

E.3 PREDICTING GAINS

  • Native-view disagreement was the only predictor passing a within-outcome screen, and only its aggregation association passed global correction.For aggregation, ρ = 0.462 with eight views (within-outcome q = 0.013) and ρ = 0.496 with 32 views (global q = 0.031); subgroup estimates were +0.567 for binary, +0.231 for regression, and −0.310 for multiclass tasks, but are descriptive.Source: §E.3 · pp. 40–41, Table 28 · p. 41
  • 13 of 14 multivariate model–outcome combinations had negative mean out-of-fold R2, and gain-magnitude prediction remained limited.The exception was ridge regression for aggregation (R2 = 0.012; mean Spearman ρ = 0.299); boosted trees had R2 = −0.083 for aggregation.Source: §E.3 · p. 41

E.4 RUNTIME AND COST ACCOUNTING

  • 177.6 hours, approximately 72% of configuration aggregation’s 247.5-hour total, went to out-of-fold member predictions.The total includes test predictions from all 96 configurations; selected-member serving was not timed.Source: Table 29 · p. 41, §E.4 · p. 42
Loading 2610.12005v1…