is trained on vast datasets and may perform a big selection of tasks. Many foundation models today are based on some variant of the transformer architecture pioneered by the likes of Google and OpenAI. Despite being resource-intensive to coach, transformer-based models can achieve high predictive performance at scale, exhibit emergent capabilities for performing tasks without explicit training, and may work with several types of input and output data. While large language models resembling ChatGPT are trained on text data, foundation models may additionally be trained on other forms of information (e.g., images, audio, and video).
Recently, some corporations with large troves of tabular data have begun investing in . These corporations are making a strategic bet that the big upfront expenditure needed to construct tabular foundation models will yield significant future returns, from increased predictive performance and productivity to unlocking recent revenue streams. Up to now, a separate tabular model typically needed to be trained per use case. For big corporations with several AI use cases, the “one model per use case” paradigm tended to incur significant costs across the model lifecycle. In contrast, one foundation model could potentially serve many use cases without delay because of the model’s emergent properties of generalization. Having “one model to rule all of them” — a lion king amongst models, should you will — seems instinctively appealing and will offer quite a lot of practical benefits.
SAP is one company that has recently created some buzz by releasing its own suite of (RPT) models — foundation models that could be trained on large sets of historical data spanning several business domains. In this text, SAP’s foray into tabular foundation models will function a concrete case study to assist us higher understand the sensible implications of providing and using such models. After situating the RPT models inside their historical context, we’ll go over their technical architecture, walk through a hands-on demonstration in Python, evaluate the professionals and cons, and discuss strategic ways forward for tabular foundation models at enterprise vendors like SAP.
Relational Pretrained Transformers
The Journey to RPT at SAP
SAP is considered one of the world’s leading providers of enterprise resource planning (ERP) software, helping businesses effectively manage critical workflows in areas starting from sales and finance to human resources and logistics. SAP has been investing in AI for several years, and until recently offered two primary kinds of AI models to customers: models optimized to be used with SAP’s ABAP language and S/4HANA database technology (e.g., see hana-ml), and narrow AI models hosted on SAP’s Business Technology Platform. For the reason that advent of ChatGPT, SAP has been developing its own suite of conversational, generative AI offerings under the Joule brand name (e.g., Joule for Consultants, Joule for Developers). The AI models underlying the Joule products are trained on SAP-specific data to deliver more relevant AI responses in use cases involving knowledge retrieval and code generation. SAP enables integrations with third-party providers of pretrained models resembling OpenAI and Anthropic via the Generative AI hub, and now, with the discharge of the SAP-RPT-1 model suite, SAP has created tabular foundation models that may be trained by itself vast trove of domain-specific ERP data.
Watch the keynote segment from 30:16 to 34:46 to see the official launch of SAP-RPT-1 at SAP TechEd 2025:
Under the Hood: Technical Architecture of SAP-RPT-1
Because the name suggests, the relational pretrained transformer (RPT) adapts the architecture of classical transformers for handling tabular (or relational) data. The initial SAP-RPT-1 models implement the ConTextTab architecture described by Spinaci et al. (2025), which in turn builds on the architecture of TabPFN, proposed by Hollmann et al. (2022).
TabPFN is a transformer model pretrained on synthetically generated tables that encapsulates several possible causal relationships between cells in individual table columns. By counting on only synthetic data, TabPFN can — perhaps surprisingly — outperform other models in use cases involving relatively small tables with lower than 10k rows of representative data that will have missing values and outliers. TabPFN can generalize to a wide range of classification tasks at inference time without the necessity for further hyperparameter optimization or fine-tuning; that is achievable through (ICL), by which a number of examples of learn how to perform recent tasks are provided as a part of the prompt for the inspiration model. Figure 1, from a follow-up Nature article by Hollmann et al. (2025), shows the workflow of (a) the pre-training and usage, and (b) the high-level architecture of TabPFN.
One drawback of coaching the TabPFN model using only synthetic data, nonetheless, is that such data doesn’t adequately capture the semantically meaningful values present in real datasets (e.g., from column names, categorical data, and free text). ConTextTab addresses this issue by training the transformer on real-world datasets and using semantic embeddings for categorical and textual data, including column names. Figure 2, from the NeurIPS article by Spinaci et al. (2025), illustrates the high-level architecture of ConTextTab.
The initial SAP-RPT-1 suite consists of three models: (a light-weight business model for fast inference and prototyping), (a much bigger business model that may achieve the next predictive performance), and (a light-weight open-source version available on HuggingFace and GitHub). The models can theoretically be used for a wide range of classification and regression tasks using few-shot in-context learning. On the time of writing, a free limited version of SAP-RPT-1 is on the market for non‑productive evaluation and testing in a playground environment — we’ll check out this model below.
Hands-On Demo
Initial Setup
To get access to the free test version of SAP-RPT-1, go to this link and check in. At the underside of the documentation, it’s best to see your personal API token — copy this right into a file called access_token.json for later use as follows:
{
"access_token": ""
} Test Dataset
Create a CSV file called sales_data_test.csv with the info shown in Table 1 below. This toy dataset will also be obtained from the SAP-RPT-1 playground environment once you will have signed in.
The duty is to predict values within the SALESGROUP column (indicated by the [PREDICT] placeholders) using values from the remaining columns. SAP-RPT-1 operationalizes few-shot ICL by requiring the input data to incorporate the next kinds of rows:
- At the very least two containing the entire data for a given record, which could be used as examples for ICL.
- At the very least one containing
[PREDICT]placeholders.
Although SAP-RPT-1 can theoretically be used for multi-target prediction, we’ll use it for single-target classification with the sales dataset.
Constructing and Posting the Prediction Request
The prediction endpoint of the SAP-RPT-1 model expects the request payload to be formatted as follows:
- Specify two top-level keys,
rowsandindex_column. - The worth of
rowsought to be the rows of the input data table represented as an inventory of dictionary objects. - The worth of
index_columnought to be the name of the index column of the input data table; this can be used as a row identifier within the model response.
The code snippet below shows learn how to create the request payload as required from sales_data_test.csv:
import pandas as pd
import json
import requests
df = pd.read_csv("sales_data_test.csv") # Load CSV file
rows = df.to_dict(orient="records") # Convert to list of dicts
index_column = "id"
payload = {
"rows": rows,
"index_column": index_column
}The resulting payload should appear to be this:
{
"rows": [
{
"PRODUCT": "Laptop",
"PRICE": 999.99,
"CUSTOMER": "Acme Corp",
"COUNTRY": "USA",
"id": "35",
"SALESGROUP": "[PREDICT]"
},
{
"PRODUCT": "Office chair",
"PRICE": 142.99,
"CUSTOMER": "Moebel Biehl",
"COUNTRY": "Germany",
"id": "571",
"SALESGROUP": "[PREDICT]"
},
{
"PRODUCT": "Desktop Computer",
"PRICE": 750.5,
"CUSTOMER": "Global Tech",
"COUNTRY": "Canada",
"id": "42",
"SALESGROUP": "Enterprise Solutions"
},
{
"PRODUCT": "Macbook",
"PRICE": 750.5,
"CUSTOMER": "Global Tech",
"COUNTRY": "Canada",
"id": "99",
"SALESGROUP": "Enterprise Solutions"
},
{
"PRODUCT": "Smartphone",
"PRICE": 499.99,
"CUSTOMER": "Mobile World",
"COUNTRY": "UK",
"id": "43",
"SALESGROUP": "Consumer Electronics"
},
{
"PRODUCT": "Office Chair",
"PRICE": 150.8,
"CUSTOMER": "Furniture Ltd",
"COUNTRY": "Germany",
"id": "44",
"SALESGROUP": "Office Furniture"
},
{
"PRODUCT": "Server Rack",
"PRICE": 1200,
"CUSTOMER": "Data Dynamics",
"COUNTRY": "Australia",
"id": "104",
"SALESGROUP": "Data Infrastructure"
},
{
"PRODUCT": "Wireless Router",
"PRICE": 89.99,
"CUSTOMER": "Tech Forward",
"COUNTRY": "India",
"id": "204",
"SALESGROUP": "Networking Devices"
}
],
"index_column": "id"
}Next, we are able to create a dictionary to define the HTTP request headers as follows:
import json
# Load the token
with open("access_token.json", "r") as token_file:
token_data = json.load(token_file)
AUTH_TOKEN = token_data["access_token"]
# Define HTTP request headers
headers = {
"Content-Type": "application/json",
"Authorization": f"Bearer {AUTH_TOKEN}"
}Finally, we are able to send the POST request and (if successful) obtain the predictions within the response:
import requests
url = "https://rpt.cloud.sap/api/predict"
response = requests.post(url, json=payload, headers=headers)
print(response.json())In case your request doesn’t succeed, listed here are some common reasons and their error codes:
- Bad Request (error code 400): Brought on by an invalid data format or a validation error. Check that the payload components (including the context and query rows) are constructed accurately.
- Unauthorized (401): Brought on by an invalid or missing API token. Make sure that your token stored in
access_token.jsonmatches the one generated for you within the SAP-RPT-1 playground. - Too Many Requests (429): Occurs if the speed limit is exceeded or the API service is temporarily unavailable. This error features a
Retry-Afterheader that indicates how long it’s best to wait before sending one other request to the API. Rate limiting ensures that the playground environment just isn’t abused and will also be utilized in the business model APIs to implement tiered pricing plans. - Service Unavailable (503): Occurs if the API server is under high load. This error also includes the
Retry-Afterheader. - Internal Server Error (500): This may increasingly occur as a consequence of another server problems on SAP side (e.g., teething issues throughout the months after product launch). Contact customer support.
Reformatting the Prediction Response
On the time of writing, when using the SAP-RPT-1 playground API with the test sales data, the response object looks something like this:
{
"prediction": {
"id": "...",
"metadata": {
"num_columns": 5,
"num_predict_rows": 2,
"num_predict_tokens": 2,
"num_rows": 6
},
"predictions": [
{
"SALESGROUP": [
{
"confidence": null,
"prediction": "Enterprise Solutions"
}
],
"id": 35
},
{
"SALESGROUP": [
{
"confidence": null,
"prediction": "Office Furniture"
}
],
"id": 571
}
]
},
"delay": 302.7692240476608,
"aiApiRequestPayload": {
"prediction_config": {
"target_columns": [
{
"name": "SALESGROUP",
"placeholder_value": "[PREDICT]",
"task_type": "classification"
}
]
},
"rows": [ ... ],
"index_column": "id",
"data_schema": {
"PRODUCT": {
"dtype": "category"
},
"PRICE": {
"dtype": "number"
},
"CUSTOMER": {
"dtype": "category"
},
"COUNTRY": {
"dtype": "category"
},
"id": {
"dtype": "number"
},
"SALESGROUP": {
"dtype": "category"
}
}
},
"aiApiResponsePayload": {
"id": "84072280-e47e-430e-91e6-008066f1a6d3",
"metadata": {
"num_columns": 5,
"num_predict_rows": 2,
"num_predict_tokens": 2,
"num_rows": 6
},
"predictions": [ ... ]
}
}What we’re typically concerned with are the values of the prediction key (i.e., the predictions and their confidence scores for the goal fields) and the delay key (showing the request processing time). Note that the business models would return non-null confidence scores as required. Moreover, it might be convenient to exchange the [PREDICT] placeholders with the anticipated values for certain downstream tasks (e.g., data imputation and auto-completion). We are able to write a helper function to merge the predictions from the API response back into the unique payload in order that it really works for arbitrary goal and index columns as follows:
def merge_predictions(payload, response_json):
# Extract index column name
index_column = payload["index_column"]
# Extract goal column(s) from the request payload config
target_columns = [
col["name"]
for col in response_json["aiApiRequestPayload"]["prediction_config"]["target_columns"]
]
# Construct a prediction map keyed by index_column
prediction_map = {}
for pred in response_json["prediction"]["predictions"]:
idx_value = pred[index_column]
prediction_map[idx_value] = {}
for goal in target_columns:
prediction_map[idx_value][target] = pred[target][0]["prediction"]
# Replace placeholders in payload rows
completed_rows = []
for row in payload["rows"]:
idx_value = row[index_column]
for goal in target_columns:
if str(row[target]).strip().upper() == "[PREDICT]":
row[target] = prediction_map.get(idx_value, {}).get(goal, row[target])
completed_rows.append(row)
return {
"rows": completed_rows,
"index_column": index_column
}
Example usage:
response_json = response.json()
if "error" in response_json:
# Example of handling a rate limit error
print(f"API error: {response_json['error']}. Retry after {response_json.get('retryAfter')} seconds.")
else:
completed_payload = merge_predictions(payload, response_json)
print(json.dumps(completed_payload, indent=2))This could reformat the payload with the anticipated values filled in:
{
"rows": [
{
"PRODUCT": "Laptop",
"PRICE": 999.99,
"CUSTOMER": "Acme Corp",
"COUNTRY": "USA",
"id": 35,
"SALESGROUP": "Enterprise Solutions"
},
{
"PRODUCT": "Office chair",
"PRICE": 142.99,
"CUSTOMER": "Moebel Biehl",
"COUNTRY": "Germany",
"id": 571,
"SALESGROUP": "Office Furniture"
},
...
],
"index_column": "id"
}Pros and Cons
Some key advantages of ICL-based tabular foundation models derive from the undeniable fact that customers can start with a classy AI model that’s pretrained on large-scale, business-relevant data, moderately than having to coach a model from scratch. On the early stages of product discovery and development, customers can iterate over prototypes of AI use cases more efficiently and cheaply by leveraging the pretrained model directly with zero- or few-shot learning. For example, working with SAP-RPT-1 models could be so simple as passing a couple of rows of information in a well-recognized, tabular format to the AI API and receiving a response with predictions in an ordinary format (e.g., JSON) that may easily be integrated into the remaining of the prototype workflow.
The mixture of a pretrained model and ICL can dramatically lower the barrier to make use of case experimentation. Offering small and enormous business models lets customers defer costs by choosing the small version during early prototyping and switching to the big version to be used in production as needed. Working with different model sizes also gives customers hands-on insights into the related trade-offs (e.g., between predictive accuracy, latency, and value, as discussed in this text), improving AI literacy. Similarly, offering open-source model versions might help educate customers, foster engagement by the developer community, and construct trust within the model provider.
Yet, the very product features lauded above may entail potential downsides that would cancel out the advantages. To effectively use ICL-based inference pipelines in production, customers should still find yourself investing significantly in areas resembling feature engineering, prompt design, retrieval-augmented generation, and model fine-tuning. Given the bespoke requirements of many use cases (especially in ERP), customers are unlikely to make use of the models with zero- or few-shot learning.
In truth, the ICL paradigm may thoroughly find yourself being (ab)used to work just like the training step in traditional supervised machine learning, by loading large training datasets into the model context for every inference call. If multiple calls are made for a similar high-usage AI scenario (e.g., predicting sales conversions based on historical transaction data), customers may find yourself loading and sending the identical large (training) dataset within the model context for several inference calls. Smart logic (e.g., context data compression, downsampling, caching, etc.) may must be implemented by the service provisioning the model and/or the consuming applications to forestall redundant, high-latency, environmentally unsustainable, and potentially insecure online data transfers (especially for high-frequency, real-time use cases).
Ultimately, without further innovation, paradigms like ICL may simply shift the prices from one “bucket” to a different (e.g., from “model training overhead” to “prompt engineering overhead” or “inference latency”) and never substantially reduce overall product development and maintenance costs — or boost the business value — of AI use cases.
Strategic Ways Forward
Marketing narratives for foundation models encourage us to assume a future by which a big portfolio of use-case-specific models is replaced by a much smaller set of generally-applicable “super models,” and even “one model to rule all of them.” After all, the instinctive appeal and craving for universal models in not unique to AI. In physics, for instance, the hunt for the “theory of every part” seeks to unify the elemental forces (gravity, electromagnetism, and the strong and weak nuclear forces) right into a single, cohesive framework. Yet such an all-encompassing theory stays elusive; different scales (e.g., cosmic vs. quantum) require different models, gravity appears to withstand integration with quantum mechanics, and we find yourself with partial unifications (e.g., quantum chromodynamics and electroweak theory). And so it might be for foundation models in AI. Indeed, throughout the SAP-RPT-1 product launch, SAP introduced not one but three model variants (large, small, and open-source). These variants spanned a minimum of two conceptual dimensions: model size (large vs. small) and transparency (closed vs. open-source).
So, trying to the long run, the interesting query just isn’t model specialization will occur, but quickly, across conceptual dimensions, and to practical effect. For an ERP vendor like SAP, as an example, it could make sense to supply specialized foundation models for a tractable set of key business processes (e.g., “source to pay,” “design to operate,” “result in money,” and “recruit to retire”). The models could further be broken down by industry or customer segment to enhance prediction quality. Even providing one specialized model per customer could be a major improvement over the establishment; each model could possibly be trained to learn customer-specific patterns (ensuring that predictions make sense in a given customer’s business context) and never run the danger of leaking sensitive information across customers (the model for customer A is not going to have seen the info used to coach the model for customer B, and thus can’t be easily hacked to disclose sensitive data patterns of B).
Finally, vendors like SAP may additionally differentiate between models which might be hosted centrally and people which might be deployed on edge devices. While centrally hosted models have several benefits (e.g., scalability, ease of updating, access to broader training data), edge-deployed models could also be better-suited to certain use case needs (e.g., device-specific tuning; regulatory requirements around handling sensitive data in healthcare; enabling real-time decision making in manufacturing, IoT, and autonomous vehicles; working in locations with patchy Web connectivity).
The Wrap
In this text we’ve covered the idea and a practical case study of relational pretrained transformers within the context of tabular foundation models. Searching through the prism of SAP’s launch of its RPT models, it becomes clear that a future by which one model rules all of them is way from preordained. At the very least based on current evidence, we usually tend to see the emergence of several specialized foundation models that reflect the intersection of assorted different conceptual dimensions (e.g., size, domain, openness) — less a lion king amongst models, and more a hive of bees, each contributing its unique strength to the collective whole. Data-rich corporations resembling SAP have several strategic options open to them of their quest to harness the ability of tabular foundation models for constructing a forward-looking ecosystem of AI tools that may evolve with business needs and technological progress.
