Одна модель, которая подойдет для всего? SAP-RPT-1 и будущее табличных базовых моделей.

Практическое исследование и рекомендации.

Делиться

Базовая модель обучается на обширных наборах данных и может выполнять широкий спектр задач. Многие современные базовые модели основаны на различных вариантах архитектуры трансформеров, разработанной такими компаниями, как Google и OpenAI. Несмотря на ресурсоемкость обучения, модели на основе трансформеров могут достигать высокой точности прогнозирования в больших масштабах, демонстрировать потенциал для выполнения задач без явного обучения и работать с различными типами входных и выходных данных. В то время как большие языковые модели, такие как ChatGPT, обучаются на текстовых данных, базовые модели могут также обучаться на других формах данных (например, изображениях, аудио и видео).

В последнее время некоторые компании, обладающие большими массивами табличных данных, начали инвестировать в базовые модели для работы с табличными данными. Эти компании делают стратегическую ставку на то, что значительные первоначальные затраты, необходимые для создания таких моделей, принесут существенную отдачу в будущем: от повышения точности прогнозирования и производительности до открытия новых источников дохода. В прошлом для каждого конкретного случая обычно приходилось обучать отдельную табличную модель. Для крупных компаний с несколькими вариантами использования ИИ парадигма «одна модель на один случай» обычно влекла за собой значительные затраты на протяжении всего жизненного цикла модели. Напротив, одна базовая модель потенциально может одновременно обслуживать множество вариантов использования благодаря своим эмергентным свойствам обобщения. Наличие «одной модели, которая будет править всеми» — своего рода «короля-льва» среди моделей — кажется интуитивно привлекательным и может предложить ряд практических преимуществ.

Компания SAP недавно привлекла к себе внимание, выпустив собственный набор реляционных предварительно обученных моделей Transformer (RPT) — базовых моделей, которые можно обучать на больших наборах исторических данных, охватывающих несколько бизнес-областей. В этой статье опыт SAP с табличными базовыми моделями послужит конкретным примером, который поможет нам лучше понять практические последствия предоставления и использования таких моделей. После рассмотрения моделей RPT в историческом контексте мы рассмотрим их техническую архитектуру, проведем практическую демонстрацию на Python, оценим преимущества и недостатки и обсудим стратегические пути развития табличных базовых моделей у корпоративных поставщиков, таких как SAP.

Реляционные предварительно обученные трансформеры

Путь к RPT в SAP

SAP — один из ведущих мировых поставщиков программного обеспечения для планирования ресурсов предприятия (ERP), помогающий компаниям эффективно управлять критически важными рабочими процессами в таких областях, как продажи и финансы, управление персоналом и логистика. SAP инвестирует в искусственный интеллект уже несколько лет и до недавнего времени предлагала клиентам два основных типа моделей ИИ: модели, оптимизированные для использования с языком ABAP SAP и технологией баз данных S/4HANA (например, см. hana-ml), и узкоспециализированные модели ИИ, размещенные на платформе SAP Business Technology Platform. С момента появления ChatGPT SAP разрабатывает собственный набор разговорных, генеративных решений ИИ под брендом Joule (например, Joule для консультантов, Joule для разработчиков). Модели ИИ, лежащие в основе продуктов Joule, обучаются на данных, специфичных для SAP, чтобы предоставлять более релевантные ответы ИИ в сценариях использования, связанных с поиском знаний и генерацией кода. SAP обеспечивает интеграцию со сторонними поставщиками предварительно обученных моделей, такими как OpenAI и Anthropic, через центр генеративного ИИ, а теперь, с выпуском набора моделей SAP-RPT-1, SAP создала табличные базовые модели, которые можно обучать на собственном обширном массиве данных ERP-систем, специфичных для конкретной предметной области.

Посмотрите фрагмент выступления с 30:16 по 34:46, чтобы увидеть официальный запуск SAP-RPT-1 на SAP TechEd 2025:

«Под капотом»: техническая архитектура SAP-RPT-1

Как следует из названия, реляционный предварительно обученный трансформер (RPT) адаптирует архитектуру классических трансформеров для обработки табличных (или реляционных) данных. Первоначальные модели SAP-RPT-1 реализуют архитектуру ConTextTab, описанную Спиначи и др. (2025), которая, в свою очередь, основана на архитектуре TabPFN, предложенной Холлманном и др. (2022).

TabPFN — это трансформерная модель, предварительно обученная на синтетически сгенерированных таблицах, которая включает в себя несколько возможных причинно-следственных связей между ячейками в отдельных столбцах таблицы. Опираясь только на синтетические данные, TabPFN может — возможно, неожиданно — превзойти другие модели в случаях использования относительно небольших таблиц с менее чем 10 000 строк репрезентативных данных, которые могут содержать пропущенные значения и выбросы. TabPFN может обобщаться на различные задачи классификации во время вывода без необходимости дальнейшей оптимизации гиперпараметров или тонкой настройки; это достигается с помощью контекстного обучения (ICL), при котором один или несколько примеров выполнения новых задач предоставляются в качестве части подсказки для базовой модели. На рисунке 1, взятом из последующей статьи Холлмана и др. (2025) в журнале Nature, показан рабочий процесс (а) предварительного обучения и использования, и (б) высокоуровневая архитектура TabPFN.

Однако одним из недостатков обучения модели TabPFN с использованием только синтетических данных является то, что такие данные неадекватно отражают семантически значимые значения, встречающиеся в реальных наборах данных (например, названия столбцов, категориальные данные и свободный текст). ConTextTab решает эту проблему, обучая трансформер на реальных наборах данных и используя семантические встраивания для категориальных и текстовых данных, включая названия столбцов. На рисунке 2 из статьи Спиначи и др. (2025) в NeurIPS показана высокоуровневая архитектура ConTextTab.

Первоначальный набор SAP-RPT-1 состоит из трех моделей: sap-rpt-1-small (легковесная коммерческая модель для быстрого вывода и прототипирования), sap-rpt-1-large (более крупная коммерческая модель, способная обеспечить более высокую точность прогнозирования) и sap-rpt-1-oss (легковесная версия с открытым исходным кодом, доступная на HuggingFace и GitHub). Теоретически эти модели могут использоваться для решения различных задач классификации и регрессии с помощью обучения в контексте с малым количеством примеров. На момент написания статьи доступна бесплатная ограниченная версия SAP-RPT-1 для непроизводительной оценки и тестирования в тестовой среде — мы протестируем эту модель ниже.

Практическая демонстрация

Первоначальная настройка

Чтобы получить доступ к бесплатной тестовой версии SAP-RPT-1, перейдите по этой ссылке и войдите в систему. Внизу документации вы увидите свой персональный API-токен — скопируйте его в файл access_token.json для дальнейшего использования следующим образом:

 { "access_token": "" }

Тестовый набор данных

Создайте CSV-файл с именем sales_data_test.csv , содержащий данные, представленные в таблице 1 ниже. Этот тестовый набор данных также можно получить из среды SAP-RPT-1 после входа в систему.

Задача состоит в том, чтобы спрогнозировать значения в столбце SALESGROUP (обозначенные заполнителями [PREDICT] ) с использованием значений из остальных столбцов. SAP-RPT-1 реализует алгоритм ICL с малым количеством выборок, требуя, чтобы входные данные включали следующие типы строк:

• По меньшей мере две контекстные строки, содержащие полные данные для данной записи, которые можно использовать в качестве примеров для ICL.
• По крайней мере, одна строка запроса содержит заполнители [PREDICT] .

Хотя SAP-RPT-1 теоретически может использоваться для прогнозирования нескольких целевых групп, мы будем использовать его для классификации одной целевой группы на основе набора данных о продажах.

Создание и размещение запроса на прогнозирование

Конечная точка прогнозирования модели SAP-RPT-1 ожидает, что полезная нагрузка запроса будет иметь следующий формат:

• Укажите два ключа верхнего уровня: rows и index_column .
• Значение rows должно представлять собой строки входной таблицы данных, представленные в виде списка объектов-словарей.
• Значение параметра index_column должно быть именем столбца индекса входной таблицы данных; оно будет использоваться в качестве идентификатора строки в ответе модели.

Приведённый ниже фрагмент кода показывает, как создать необходимую полезную нагрузку запроса из 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 }

В результате полезная нагрузка должна выглядеть следующим образом:

 { "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" }

Далее мы можем создать словарь для определения заголовков HTTP-запроса следующим образом:

 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}" }

Наконец, мы можем отправить POST-запрос и (в случае успеха) получить прогнозы в ответе:

 import requests url = "https://rpt.cloud.sap/api/predict" response = requests.post(url, json=payload, headers=headers) print(response.json())

Если ваш запрос не удался, вот несколько распространенных причин и соответствующие коды ошибок:

• Неверный запрос (код ошибки 400): вызван недопустимым форматом данных или ошибкой проверки. Убедитесь, что компоненты полезной нагрузки (включая контекст и строки запроса) сформированы правильно.
• Ошибка авторизации (401): вызвана недействительным или отсутствующим токеном API. Убедитесь, что ваш токен, хранящийся в файле access_token.json , совпадает с токеном, сгенерированным для вас в тестовой среде SAP-RPT-1.
• Слишком много запросов (429): Эта ошибка возникает, если превышен лимит запросов или API-сервис временно недоступен. В заголовке Retry-After указывается, как долго следует ждать перед отправкой следующего запроса к API. Ограничение скорости запросов гарантирует, что среда тестирования не будет использоваться не по назначению, и может также применяться в коммерческих API для реализации многоуровневых тарифных планов.
• Ошибка «Сервис недоступен» (503): возникает, если API-сервер находится под высокой нагрузкой. Эта ошибка также содержит заголовок Retry-After .
• Внутренняя ошибка сервера (500): Это может быть связано с другими проблемами на стороне SAP (например, с проблемами на начальном этапе после запуска продукта). Обратитесь в службу поддержки клиентов.

Переформатирование ответа прогноза

На момент написания этой статьи при использовании API SAP-RPT-1 Playground с тестовыми данными о продажах объект ответа выглядит примерно так:

 { "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": [ ... ] } }

Как правило, нас интересуют значения ключа prediction (т.е., сами прогнозы и их оценки достоверности для целевых полей) и ключа delay (показывающего время обработки запроса). Обратите внимание, что коммерческие модели возвращают ненулевые оценки достоверности по мере необходимости. Кроме того, может быть удобно заменить заполнители [PREDICT] прогнозируемыми значениями для некоторых последующих задач (например, для заполнения пропущенных данных и автозаполнения). Мы можем написать вспомогательную функцию для объединения прогнозов из ответа API обратно в исходную полезную нагрузку, чтобы она работала для произвольных целевых и индексных столбцов следующим образом:

 def merge_predictions(payload, response_json): # Extract index column name index_column = payload["index_column"] # Extract target column(s) from the request payload config target_columns = [ col["name"] for col in response_json["aiApiRequestPayload"]["prediction_config"]["target_columns"] ] # Build 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 target 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 target in target_columns: if str(row[target]).strip().upper() == "[PREDICT]": row[target] = prediction_map.get(idx_value, {}).get(target, row[target]) completed_rows.append(row) return { "rows": completed_rows, "index_column": index_column }

Пример использования:

 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))

Это должно переформатировать полезную нагрузку, заполнив ее прогнозируемыми значениями:

 { "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" }

Плюсы и минусы

Ключевые преимущества табличных базовых моделей на основе ICL обусловлены тем, что клиенты могут начать с уже обученной сложной модели ИИ, созданной на больших объемах данных, имеющих отношение к бизнесу, вместо того, чтобы обучать модель с нуля. На ранних этапах разработки и создания продукта клиенты могут более эффективно и дешево дорабатывать прототипы сценариев использования ИИ, используя предварительно обученную модель напрямую с помощью обучения с нулевым или малым количеством примеров. Например, работа с моделями SAP-RPT-1 может быть такой же простой, как передача нескольких строк данных в привычном табличном формате в API ИИ и получение ответа с прогнозами в стандартном формате (например, JSON), который легко интегрируется в остальную часть рабочего процесса прототипирования.

Сочетание предварительно обученной модели и ICL может значительно снизить барьер для экспериментов с различными вариантами использования. Предложение небольших и крупных коммерческих моделей позволяет клиентам откладывать затраты, выбирая небольшую версию на ранних этапах прототипирования и переключаясь на большую версию для использования в производстве по мере необходимости. Работа с моделями разных размеров также дает клиентам практическое понимание компромиссов (например, между точностью прогнозирования, задержкой и стоимостью, как обсуждается в этой статье), повышая уровень знаний в области ИИ. Аналогично, предложение версий моделей с открытым исходным кодом может помочь обучить клиентов, стимулировать взаимодействие со стороны сообщества разработчиков и укрепить доверие к поставщику моделей.

Однако, упомянутые выше характеристики продукта могут таить в себе потенциальные недостатки, которые могут нивелировать преимущества. Для эффективного использования конвейеров вывода на основе ICL в производственной среде клиентам, возможно, все равно придется вкладывать значительные средства в такие области, как разработка признаков, проектирование подсказок, генерация с расширением поиска и тонкая настройка модели. Учитывая специфические требования многих сценариев использования (особенно в ERP-системах), клиенты вряд ли будут использовать модели с обучением с нулевым или малым количеством примеров.

Фактически, парадигма ICL вполне может быть (неправильно) использована в качестве этапа обучения в традиционном контролируемом машинном обучении, загружая большие обучающие наборы данных в контекст модели для каждого вызова вывода. Если для одного и того же сценария ИИ с высокой частотой использования (например, прогнозирование конверсии продаж на основе исторических данных о транзакциях) выполняется несколько вызовов, клиенты могут в конечном итоге загружать и отправлять один и тот же большой (обучающий) набор данных в контекст модели для нескольких вызовов вывода. Для предотвращения избыточных, высокозадержечных, экологически неустойчивых и потенциально небезопасных онлайн-передач данных (особенно для высокочастотных сценариев использования в реальном времени) может потребоваться реализация интеллектуальной логики (например, сжатие контекстных данных, уменьшение выборки, кэширование и т. д.) сервисом, предоставляющим модель, и/или приложениями-потребителями.

В конечном итоге, без дальнейших инноваций, такие парадигмы, как ICL, могут просто перераспределить затраты из одной «категории» в другую (например, из «накладных расходов на обучение модели» в «накладные расходы на оперативное проектирование» или «задержку при выводе») и не привести к существенному снижению общих затрат на разработку и поддержку продукта, а также не повысить коммерческую ценность вариантов использования ИИ.

Стратегические пути развития

Маркетинговые нарративы, посвященные базовым моделям, побуждают нас представить будущее, в котором большой портфель моделей, специфичных для конкретных сценариев использования, будет заменен гораздо меньшим набором общеприменимых «супермоделей» или даже «одной моделью, которая будет управлять всем». Конечно, инстинктивная привлекательность и стремление к универсальным моделям не уникальны для ИИ. В физике, например, поиск «теории всего» направлен на объединение фундаментальных сил (гравитации, электромагнетизма, а также сильного и слабого ядерных взаимодействий) в единую, целостную структуру. Однако такая всеобъемлющая теория остается недостижимой; разные масштабы (например, космический и квантовый) требуют разных моделей, гравитация, по-видимому, сопротивляется интеграции с квантовой механикой, и в итоге мы получаем частичные объединения (например, квантовая хромодинамика и электрослабая теория). То же самое может быть и с базовыми моделями в ИИ. Действительно, во время запуска продукта SAP-RPT-1 компания SAP представила не один, а три варианта модели (большую, малую и с открытым исходным кодом). Эти варианты охватывали как минимум два концептуальных измерения: размер модели (большая против малой) и прозрачность (закрытая против открытого исходного кода).

Таким образом, заглядывая в будущее, интересный вопрос заключается не в том, произойдет ли специализация моделей, а в том, как быстро, по каким концептуальным направлениям и к какому практическому эффекту это приведет. Например, для такого поставщика ERP-систем, как SAP, было бы целесообразно предлагать специализированные базовые модели для управляемого набора ключевых бизнес-процессов (например, «от закупки до оплаты», «от проектирования до эксплуатации», «от привлечения клиента до получения оплаты» и «от найма до увольнения»). Модели можно было бы дополнительно разбить по отраслям или сегментам клиентов для повышения качества прогнозирования. Даже предоставление одной специализированной модели для каждого клиента стало бы значительным улучшением по сравнению с текущим положением дел; каждая модель могла бы быть обучена для выявления специфических для клиента закономерностей (гарантируя, что прогнозы имеют смысл в контексте бизнеса данного клиента) и не подвергаться риску утечки конфиденциальной информации между клиентами (модель для клиента А не видела данных, использованных для обучения модели для клиента В, и, следовательно, ее нельзя было бы легко взломать, чтобы раскрыть конфиденциальные данные о закономерностях В).

Наконец, такие поставщики, как SAP, могут также различать модели, размещенные централизованно, и модели, развернутые на периферийных устройствах. Хотя централизованно размещенные модели имеют ряд преимуществ (например, масштабируемость, простота обновления, доступ к более широкому объему обучающих данных), модели, развернутые на периферии, могут лучше подходить для определенных сценариев использования (например, настройка под конкретное устройство; нормативные требования к обработке конфиденциальных данных в здравоохранении; обеспечение принятия решений в режиме реального времени в производстве, Интернете вещей и автономных транспортных средствах; работа в местах с нестабильным интернет-соединением).

The Pack

В этой статье мы рассмотрели теорию и практический пример реляционных предварительно обученных трансформеров в контексте табличных базовых моделей. Рассматривая запуск SAP своих моделей RPT, становится ясно, что будущее, в котором одна модель будет править всеми, далеко не предопределено. По крайней мере, судя по имеющимся данным, мы, скорее всего, увидим появление нескольких специализированных базовых моделей, отражающих пересечение различных концептуальных измерений (например, размер, предметная область, открытость) — не столько «король-лев» среди моделей, сколько улей пчел, каждая из которых вносит свой уникальный вклад в общее целое. Компании, обладающие большими объемами данных, такие как SAP, имеют несколько стратегических вариантов в своем стремлении использовать возможности табличных базовых моделей для построения перспективной экосистемы инструментов ИИ, которая может развиваться вместе с потребностями бизнеса и технологическим прогрессом.

Чинмай Какаткар: посмотреть все в Чинмай Какаткар

Источник: towardsdatascience.com