Proposal: zero-shot tabular foundation model (ruvector-tabfm / TabPFN-v2) — ADR-272

Proposal: a zero-shot tabular foundation model for RuVector (ruvector-tabfm / ruvector-tabpfn)

Inspired by Google's TabFM (zero-shot classification/regression on tables via in-context learning). This issue proposes adding the tabular member of the foundation-model family RuVector already ships for time series — and leaves the how/whether to maintainer decision.

Full write-up in the companion PR: ADR-272 + docs/research/tabfm/PLAN.md + a runnable, license-clean benchmark.

Why it fits RuVector (not just a novelty)

• We already ran this play. crates/ruvector-timesfm is a candle port of TimesFM wired inward into the DB's own machinery (sweep::EarlyStopper, rebuild, anomaly). TabFM/TabPFN is the tabular sibling — same "port it and point it inward" pattern.
• Native synergy. A tabular FM's row-compression stage turns a heterogeneous row (numeric + categorical) into one dense vector — exactly what the vector DB indexes. "Embed a structured record" becomes free, reusing HNSW/DiskANN untouched.
• On-brand. Zero-config, self-optimizing, local, $0/query, WASM-able — matches RuVector's positioning.

The licensing gate (resolved) — the important part

A candle port of the non-commercial weights is a Derivative that inherits the terms → incompatible with RuVector (MIT/Apache, bundled in npx ruvector, powering commercial Cognitum). TabPFN-v2 is the shippable base (attribution: show "Built with PriorLabs-TabPFN"; prefix any distilled/distributed model name with "TabPFN"; internal benchmarking exempt).

Track A benchmark — is the shippable model actually good? (GO)

Shippable TabPFN-v2, zero-shot, on CPU vs tuned trees (nested 5-fold CV; XGBoost/HistGBM get a real RandomizedSearchCV per fold; TabPFN gets no tuning). ROC AUC, 6 standard OpenML datasets. Script + results in the PR.

Top-or-tied on 5/6 zero-shot; big multiclass win on vehicle (+0.034 AUC / +8.5 pts acc); only loss credit-g (−0.009, within noise). Binary margins are small-but-consistent — the value is "as good as tuned trees, zero tuning, ~1s, local." The gated v2.5/v3 weights refused to load without license acceptance, corroborating the gate.

Honest caveats: 6 small datasets = a confirmation run, not a SOTA proof (see published TabArena for that); v2's in-context design caps table size (~10k rows) → small/medium tables + warm-starts, not billion-row training; the newer (non-commercial) weights would likely widen the accuracy gap, but can't ship.

Highest-impact uses (ranked, for discussion)

1. Core candle port ruvector-tabfm/ruvector-tabpfn, mirroring ruvector-timesfm (predict + tab_predict MCP tool + WASM).
2. Row-compression → tabular-row embedder (row → one indexable vector; new retrieval modality, deepest DB synergy).
3. Inward zero-shot autotuner — predict HNSW/IVF/quant knobs from workload features; warm-starts SONA (compounds the ADR-205/206/271 line).
4. Postgres ruvector_tab_predict() = a local, free analog of BigQuery AI.PREDICT.

Deferred: tabular reranker (query hot-path latency); training our own weights on a synthetic-SCM engine (now optional headroom since TabPFN-v2 is shippable, not a prerequisite).

Ask

This is research + plan only — no product code. Opening it for @ruvnet to decide whether to pursue and which surface to build first (or to run the ceiling benchmark against the gated v2.5/v3 weights). Companion PR adds the ADR, plan, and reproducible benchmark.

Start by reading ADR-272 and docs/research/tabfm/PLAN.md, then inspect the companion benchmark and its results. The issue is research and planning only; done requires a maintainer decision about whether to pursue TabPFN-v2 and which proposed surface to build first.