Requête en langage naturel sur des données SAP — schémas et limites du text-to-SQL

Deux techniques sous une seule étiquette

« Posez une question à vos données en langage courant » décrit deux mécanismes structurellement différents, et les confondre dans une proposition est la façon dont une estimation de delivery part de travers. Le premier, le NLQ médié par la couche sémantique, est ce que fait Just Ask de SAC et, par ce biais, les Analytical Insights de Joule : la question est mise en correspondance avec un modèle analytique préconstruit — mesures, hiérarchies, libellés déjà définis et revus (C353) — et la réponse ne peut jamais être plus flexible que ce modèle. Le second, le text-to-SQL, laisse un LLM lire les métadonnées de tables et de colonnes d'un catalogue gouverné et générer sa propre requête à la volée, plus proche de ce que fait Databricks Genie contre le Unity Catalog : aucun modèle préconstruit ne contraint la question, mais rien de préconstruit ne protège non plus la réponse.

Pourquoi c'est important

• « Requête en langage naturel » n'est pas une seule technique : le NLQ médié par la couche sémantique et le text-to-SQL échouent de manières opposées — l'un échoue visiblement par silence, l'autre invisiblement par plausibilité — et cadrer sans nommer lequel laisse le vrai risque non traité.
• La gouvernance de contrôle d'accès (permissions du catalogue) et la justesse sémantique (la requête signifie-t-elle ce que le métier signifie) sont des garanties différentes ; le text-to-SQL peut livrer parfaitement la première tout en échouant sur la seconde.
• La plupart des besoins métier pour « poser n'importe quelle question à vos données » s'avèrent, à y regarder de près, être des besoins de réponses fiables à un ensemble borné de questions — le cas médié par la couche sémantique, pas le cas ouvert que la formule suggère.

Points clés

• NLQ médié par la couche sémantique (Just Ask, Analytical Insights de Joule) : répond uniquement via un vocabulaire préconstruit et revu ; échoue par silence ou par une lacune de modèle traçable.
• Text-to-SQL (schéma type Genie) : un LLM lit les métadonnées du catalogue et écrit sa propre requête ; échoue par plausibilité — une réponse syntaxiquement valide, fausse avec assurance.
• La gouvernance (qui peut voir quoi) repose sur le catalogue dans les deux schémas et est bien traitée ; la justesse sémantique (la requête signifie-t-elle ce que le métier signifie) est structurellement plus difficile pour le text-to-SQL.
• Les deux ne s'excluent pas mutuellement au sein d'une même architecture — questions routinières via NLQ par couche sémantique, charges exploratoires via text-to-SQL sur les mêmes data products (C349).
• Une proposition nommant seulement « requête en langage naturel » sans préciser le schéma n'a cadré ni les compétences, ni les modes d'échec, ni le discours de gouvernance qui diffèrent entre les deux.
• La plupart des besoins métier réels visent des réponses fiables à un ensemble borné de questions — le cas de la couche sémantique — même formulés comme « posez n'importe quelle question ».

Termes employés sur cette page

NLQ médié par la couche sémantique

Requête en langage naturel dont la réponse passe par un modèle analytique préconstruit avec des mesures, hiérarchies et libellés gouvernés.

Text-to-SQL

Une approche où un LLM génère et exécute sa propre requête sur des tables cataloguées, sans modèle sémantique préconstruit.

Gouvernance au niveau du catalogue

Contrôle d'accès appliqué par le catalogue de données (p. ex. Unity Catalog), quel que soit le schéma de requête utilisé par-dessus.

Réponse fausse avec assurance

Une réponse d'apparence syntaxiquement ou fluidement correcte qui est sémantiquement incorrecte et ne donne aucun signal visible de l'erreur.

Sources

1. SAP News Center — SAP Business AI: Release Highlights Q1 2026 (base for the Just Ask/Analytical Insights semantic-layer path)