SAP et l'ICL : Optimisation contextuelle des modèles tabulaires

SAP et l'ICL : Une nouvelle ère pour les modèles tabulaires

L'essor de l'apprentissage contextuel

Au cours des dernières années, nous avons assisté à une augmentation significative des investissements dans des modèles fondamentaux tabulaires, qu'ils soient open-source ou commerciaux, construits autour de l'apprentissage contextuel (ICL). En 2025, le géant du logiciel SAP a introduit la suite de modèles SAP-RPT-1, conçue pour répondre à des tâches centrées sur l'ERP dans des domaines tels que la planification financière, le traitement des commandes de vente et d'approvisionnement, ainsi que la gestion de la chaîne d'approvisionnement. Contrairement à l'apprentissage supervisé traditionnel, où les modèles sont formés et ajustés pour des tâches spécifiques, l'ICL permet à un modèle pré-entraîné de s'adapter en temps réel en utilisant des quantités relativement petites de données spécifiques à la tâche fournies dans la charge utile contextuelle, qui agit comme un ensemble d'entraînement éphémère.

Les défis de l'ICL : Précision vs Latence

Bien que le passage à l'ICL élimine le besoin de reformer des modèles tabulaires spécifiques à la tâche, il introduit un compromis important entre précision et latence au moment de l'inférence, en particulier pour des modèles hébergés de manière centralisée comme SAP-RPT-1. D'une part, le temps nécessaire pour envoyer la charge utile contextuelle au serveur du modèle, et pour que le modèle interprète et apprenne de cette charge, contribue directement à la latence de réponse globale. Des charges utiles plus petites peuvent réduire la latence. D'autre part, le modèle peut avoir besoin d'inférer des schémas complexes et des distributions de données à partir de données contextuelles hétérogènes qui peuvent contenir des valeurs aberrantes, des valeurs manquantes et des motifs de longue traîne. Des prédictions précises dépendent généralement de charges utiles contextuelles grandes et bien organisées. En pratique, cela signifie trouver des moyens de distiller la charge utile contextuelle pour réduire le temps de réponse sans dégrader la performance prédictive du modèle. Les compromis secondaires impliquent des facteurs tels que le débit de service du modèle, la stabilité des réponses et le coût monétaire de l'utilisation du modèle. Tous ces défis font de l'optimisation de la charge utile contextuelle une préoccupation architecturale centrale dans les flux de travail basés sur l'ICL.

Compromis au moment de l'inférence

Une approche efficace pour analyser les compromis au moment de l'inférence des modèles fondamentaux tabulaires basés sur l'ICL consiste à appliquer le cadre du « triangle de fer ». Ce concept aide à naviguer dans les tensions inhérentes entre la qualité de réponse, le coût d'inférence et la latence, qui est un analogue au moment de l'inférence du classique « triple contrainte » en gestion de projet. Il est crucial de noter que l'amélioration de l'une de ces dimensions met généralement la pression sur les autres : des réponses de meilleure qualité tendent à être plus intensives en calcul, ce qui augmente à la fois la latence et le coût ; réduire la latence nécessite souvent de sacrifier la qualité ou de payer plus pour du matériel plus rapide ; et diminuer le coût signifie généralement accepter des réponses d'IA plus lentes ou de moindre qualité.

Nous rencontrons cette même tension triangulaire dans le contexte des modèles fondamentaux tabulaires basés sur l'ICL. Le compromis principal est la nécessité d'équilibrer la qualité de réponse (mesurée en termes de précision, rappel, etc.) par rapport à la latence. Considérons un système de détection de fraude en temps réel déployé aux DAB : à la fois la précision et la rapidité sont critiques, mais elles tirent le système dans des directions différentes en ce qui concerne la construction de la charge utile contextuelle. Des charges utiles plus grandes et plus riches donnent au modèle d'IA plus d'exemples à partir desquels inférer le schéma sous-jacent, reconnaître des motifs rares et de longue traîne, et ainsi fournir des prédictions de meilleure qualité. En même temps, chaque ligne ou caractéristique supplémentaire augmente le volume de données qui doit être envoyé au serveur du modèle et interprété lors de l'inférence, ce qui peut introduire un surcoût mesurable au temps de réponse de bout en bout. Dans les applications en temps réel, même une petite augmentation de la taille de la charge utile peut dégrader de manière significative la réactivité du système et, finalement, nuire à l'expérience utilisateur.

Compromis secondaires et implications

De plus, plusieurs compromis secondaires émergent en pratique. Une charge utile contextuelle plus grande ralentit non seulement l'inférence, mais consomme également plus de tokens. Dans le cadre de la facturation basée sur les tokens, cela crée une tension entre la latence de réponse et le coût monétaire de l'utilisation du modèle pour les clients, ce qui devient particulièrement pertinent pour des modèles hébergés de manière centralisée comme SAP-RPT-1. Une charge utile plus grande peut augmenter le temps de calcul par requête, créant un compromis latence-débit qui peut contraindre l'équipe de développement du système d'IA à prendre des décisions difficiles en matière d'évolutivité. Il existe également un compromis potentiel entre qualité et stabilité : augmenter le volume et la variété des données contextuelles peut améliorer la précision prédictive mais peut réduire le déterminisme en introduisant du bruit et en rendant les sorties plus sensibles aux petites variations des données. Enfin, des méthodes de sélection de charge utile plus sophistiquées, telles que la récupération basée sur les KNN, peuvent améliorer la qualité des prédictions mais également augmenter le temps de construction de la charge utile, ajoutant à la latence globale.

Stratégies d'optimisation de la charge utile contextuelle

En général, les stratégies d'optimisation de la charge utile contextuelle s'étendent sur deux dimensions orthogonales : la méthode et le moment de l'optimisation. La méthode d'optimisation détermine comment exactement la charge utile est élaborée, c'est-à-dire les techniques spécifiques de filtrage, de regroupement ou d'encodage utilisées pour compresser les lignes dans le contexte brut. Le moment de l'optimisation concerne quand et où l'optimisation est effectuée, par exemple, si elle est pré-calculée hors ligne ou dérivée à la volée au moment de l'inférence, et si cela est fait par le client ou le service du modèle. Choisir un moment particulier pour construire la charge utile optimisée peut avoir des conséquences importantes sur la latence d'inférence et la maintenabilité. La méthode et le moment de l'optimisation de la charge utile doivent être alignés avec la portée, le budget, le seuil de latence et les exigences de qualité d'un cas d'utilisation d'IA donné.

Méthodes d'optimisation

Nous pouvons distinguer de manière générale entre des méthodes d'optimisation agnostiques à la tâche et sensibles à la tâche. Les méthodes agnostiques à la tâche reposent sur des techniques telles que l'échantillonnage aléatoire et l'échantillonnage basé sur la récence, qui ne nécessitent pas de connaissance de la tâche de prédiction spécifique ou de la structure sémantique des données. L'échantillonnage aléatoire est facile à mettre en œuvre, rapide et impartial, ce qui en fait une stratégie de base ou de secours utile. Cependant, il peut involontairement écarter des lignes qui capturent des motifs rares mais importants cruciaux pour la performance du modèle. L'échantillonnage basé sur la récence suppose que des horodatages sont enregistrés dans les données et récupère les lignes les plus récentes, ce qui peut être précieux pour des distributions de données liées au temps (par exemple, saisonnières) ou susceptibles de dérive temporelle. Cependant, l'échantillonnage basé sur la récence ignore la structure plus large de l'ensemble de données et peut surpondérer le bruit à court terme. Dans l'ensemble, les méthodes agnostiques à la tâche offrent simplicité et rapidité mais fournissent un contrôle limité sur la représentativité et la pertinence de la charge utile résultante.

En revanche, les méthodes sensibles à la tâche peuvent intégrer des informations sur la tâche de prédiction, les lignes de requête et la distribution sous-jacente des données pour sélectionner les lignes les plus pertinentes pour la charge utile contextuelle. Une approche courante est l'échantillonnage par K-plus proches voisins (KNN), qui identifie les lignes dans les données historiques similaires aux lignes de requête. Cela peut produire des données contextuelles très pertinentes et une forte performance empirique, mais nécessite des métriques de distance (par exemple, cosinus) et des modèles auxiliaires pour vectoriser ou intégrer les données, et peut donc être coûteux en calcul à grande échelle. Une autre classe de techniques utilise des algorithmes de regroupement (par exemple, K-means, regroupement hiérarchique, DBSCAN) pour tirer des échantillons représentatifs de clusters pertinents pour les lignes de requête. Cela peut garantir une couverture suffisante des motifs divers dans les données tout en évitant la redondance, bien que cela nécessite généralement un calcul hors ligne des clusters et une recomposition périodique pour garantir que les clusters restent à jour.

Des méthodes plus sophistiquées sensibles à la tâche sont également possibles. Par exemple, le contexte brut et les lignes de requête peuvent être intégrés dans un espace vectoriel de faible dimension – encodé dans la requête et décodé dans la réponse de l'API du modèle fondamental ; cela revient à une forme de compression avec perte qui sacrifie une certaine précision pour les avantages de latence et de coût d'une charge utile plus petite. Les techniques de génération augmentée par récupération (RAG) peuvent enrichir davantage la charge utile avec un ancrage spécifique au domaine pour améliorer la pertinence de la réponse.

En résumé, les méthodes sensibles à la tâche produisent généralement des charges utiles contextuelles de meilleure qualité mais s'accompagnent d'une surcharge d'ingénierie et de calcul plus importante.

Moments d'optimisation

Une décision clé liée au moment concerne la possibilité de pré-calculer certaines étapes d'optimisation de la charge utile hors ligne (c'est-à-dire le « quand »). Par exemple, un ensemble de données « doré » peut être pré-calculé à partir de données historiques, optimisé pour la densité d'information et enrichi avec des métadonnées (par exemple, identifiants de cluster, hashtags, etc.). Des lignes pertinentes peuvent être sélectionnées à partir de cet ensemble de données doré plus léger pour construire et envoyer rapidement la charge utile contextuelle au moment de l'inférence. Les ensembles de données dorées sont bien adaptés aux schémas stables et aux tâches répétitives (par exemple, l'auto-complétion de commandes de vente courantes dans le domaine de l'ERP), mais leur élaboration et leur maintenance peuvent créer une surcharge supplémentaire pour l'équipe de développement. En revanche, l'optimisation à la volée dérive la charge utile au moment de l'inférence en fonction des lignes de requête actuelles et des données historiques disponibles. Cette approche est plus adaptative mais peut augmenter le coût de calcul et la latence pour chaque appel d'inférence. L'optimisation à la volée ne réduit pas nécessairement la surcharge de l'équipe de développement : les économies réalisées en ne maintenant pas un ensemble de données doré peuvent être compensées par l'effort d'ingénierie nécessaire pour optimiser dynamiquement la charge utile contextuelle.

Une autre décision liée au moment concerne le fait que l'optimisation se déroule du côté du client ou du service.