Databricks ai_decide fait passer les données gouvernées de l’analyse à l’action

Databricks a lancé Databricks ai_decide le 30 septembre, en ajoutant une fonction SQL en bêta qui transforme des données gouvernées en probabilités, choix et scores. Le conflit est immédiat. Les entreprises veulent des décisions assistées par l’IA à la vitesse des données, mais les choix opérationnels exigent davantage de responsabilité que la génération de texte ordinaire.

La nouvelle fonction évalue des enregistrements structurés ou du texte au regard d’une grille fournie par l’utilisateur. Elle peut estimer si un événement requiert une attention, choisir parmi des résultats nommés ou noter un cas sur une échelle ordonnée. Ces résultats peuvent ensuite alimenter une autre requête SQL, un workflow ou une application.

Cette annonce est donc plus importante qu’un simple endpoint de modèle supplémentaire. Databricks intègre le jugement fondé sur les modèles au sein du workflow de données, là où les équipes contrôlent déjà les tables, les autorisations, les pipelines et la logique métier. Google Cloud propose des fonctions génératives connexes dans BigQuery, tandis que les API de modèles généralistes permettent aux développeurs de construire manuellement des systèmes similaires. La compétition porte désormais sur la capacité à opérationnaliser des décisions probabilistes sans dissimuler leur incertitude.

Databricks ai_decide transforme un appel SQL en plusieurs décisions

Le changement important n’est pas que Databricks puisse appeler un modèle depuis SQL. C’est qu’une fonction gouvernée puisse renvoyer plusieurs évaluations prêtes à guider une décision concernant le même enregistrement.

Selon le billet de lancement de l’entreprise, Databricks ai_decide est destiné à prendre rapidement des décisions à partir de données d’entreprise gouvernées. La fonction s’inscrit dans la famille plus large des AI Functions spécialisées de l’entreprise.

Sa syntaxe comporte trois éléments : un état, un ensemble de questions et des paramètres de version facultatifs. L’état contient les éléments de preuve évalués. Il peut s’agir de texte ordinaire, d’un objet encodé en JSON, d’un tableau JSON ou d’un VARIANT généré par une autre AI Function.

Les questions sont définies une seule fois pour l’appel et appliquées à chaque ligne d’entrée. Chaque question comprend des instructions et un type de réponse. Certains types exigent également des critères décrivant les résultats disponibles.

La référence de la fonction documente trois types de réponse :

• noul estime la probabilité qu’une affirmation soit vraie, en renvoyant un nombre compris entre 0 et 1.

• choice sélectionne une étiquette parmi jusqu’à 255 critères nommés et renvoie les probabilités pour chaque étiquette.

• score évalue l’entrée par rapport à une échelle ordonnée contenant entre 2 et 10 critères.

Le terme inhabituel noul désigne une évaluation probabiliste par oui ou non. Au lieu d’imposer une réponse booléenne, la fonction indique une vraisemblance estimée. Cette distinction compte lorsque les systèmes en aval ont besoin de seuils plutôt que d’affirmations absolues.

Une organisation de support, par exemple, pourrait demander si un ticket nécessite une escalade immédiate. Elle pourrait également demander quelle équipe doit prendre en charge le dossier et quel semble être le degré d’urgence. Ces trois évaluations peuvent utiliser le même ticket comme élément de preuve.

Le résultat est un VARIANT contenant une réponse, des métadonnées et un champ d’erreur. Un VARIANT est un type de données flexible destiné aux valeurs semi-structurées, telles que le JSON imbriqué. Les appels réussis identifient la version de la fonction, tandis que les appels échoués peuvent renvoyer une description de l’erreur.

Pour les questions de type choix, la sortie inclut l’étiquette sélectionnée, les probabilités de chaque étiquette possible et une valeur de confiance. Les questions de type score incluent un score numérique, les descriptions de l’échelle d’origine, les probabilités et la confiance.

Cette conception donne aux analystes davantage d’informations qu’une unique étiquette générée. Un workflow peut accepter automatiquement les décisions à forte confiance, orienter les cas incertains vers des personnes et enregistrer la distribution de probabilités pour un examen ultérieur.

Databricks avertit également que les réponses générées peuvent varier d’un appel à l’autre. Cette déclaration est facile à négliger, mais elle définit le principal défi opérationnel. La syntaxe SQL rend la fonction accessible et composable. Elle ne rend pas le jugement sous-jacent déterministe.

Les décisions d’IA gouvernées mettent les équipes data sous pression

Databricks ai_decide pousse les équipes data à traiter le jugement du modèle comme une logique de production, et non comme une sortie expérimentale copiée depuis un chatbot.

De nombreuses décisions d’entreprise commencent déjà dans un entrepôt de données ou un lakehouse. Les tickets de support, fiches produits, documents d’assurance, rapports d’incident, candidatures et enregistrements de transactions deviennent finalement des lignes traitées par des pipelines.

Le SQL traditionnel fonctionne bien lorsque la décision peut être formulée comme une règle exacte. Une transaction dépassant un montant fixe peut rejoindre une file de vérification. Un ticket portant un code d’erreur connu peut être envoyé à une équipe précise.

Les cas plus difficiles dépendent du sens. Un client peut décrire une interruption de service sans utiliser le vocabulaire officiel de l’entreprise pour les incidents. Une fiche produit peut suggérer une adéquation sans correspondre à une taxonomie contrôlée. Un dossier peut satisfaire simultanément plusieurs priorités concurrentes.

Les organisations gèrent souvent ces situations via des files manuelles ou des services de modèles externes. L’examen manuel peut être lent. Les services externes ajoutent du code, des transferts de données, des identifiants, de la surveillance et du travail de gouvernance.

Databricks ai_decide raccourcit ce parcours. Une équipe peut exprimer une grille qualitative à côté des données et recevoir des évaluations structurées dans SQL. Ces évaluations peuvent ensuite participer à des filtres, jointures, tableaux de bord, pipelines Lakeflow, Workflows ou à la logique d’une application.

La présentation générale des AI Functions décrit des fonctions intégrées pour l’analyse de documents, l’extraction, la classification, la préparation à la recherche et d’autres transformations. Databricks ai_decide ajoute une couche de décision explicite après ces étapes de préparation.

Prenons un workflow documentaire. ai_parse_document peut convertir un document importé en contenu structuré. ai_extract peut identifier des champs précis. Databricks ai_decide peut ensuite évaluer le VARIANT obtenu au regard d’une grille métier.

Cette séquence modifie qui peut construire le workflow. Un ingénieur data n’a plus besoin d’encapsuler chaque décision dans un service personnalisé. Un analyste peut examiner l’état, les critères, les réponses, les probabilités et les erreurs à l’aide d’outils de données familiers.

Elle modifie également qui devient responsable. Dès lors qu’un score généré par l’IA contrôle le routage ou la priorisation, l’équipe data est responsable de bien plus que les performances des requêtes. Elle doit contribuer à définir les taux d’erreur acceptables, les seuils d’escalade, les règles de surveillance et le comportement de repli.

La gouvernance devient une partie de la conception du produit. Databricks indique que les données documentaires restent dans son périmètre de sécurité. L’entreprise affirme ne pas stocker les paramètres transmis aux appels AI Function, même si elle conserve des métadonnées d’exécution telles que la version du runtime.

L’accès n’est pas automatiquement restreint. La documentation de Databricks indique que les utilisateurs reçoivent par défaut l’autorisation EXECUTE sur le schéma system.ai lorsque la préversion concernée est activée. Les administrateurs doivent supprimer cette autorisation au niveau du schéma avant d’accorder l’accès à certaines fonctions ou certains groupes.

Ces contrôles d’accès sont eux-mêmes en préversion publique et nécessitent une activation. Ils s’appliquent aux fonctions spécialisées sous system.ai, mais ne régissent pas la fonction généraliste ai_query.

Cette limite compte. Une entreprise ne peut pas supposer que l’activation d’un mécanisme de gouvernance couvre toutes les voies d’accès à un modèle. Les administrateurs ont besoin de politiques distinctes pour les AI Functions spécialisées et les appels directs à Model Serving.

Le lancement exerce donc simultanément une pression sur les responsables de plateforme, les équipes de sécurité et les dirigeants opérationnels. Les responsables de plateforme doivent rendre la fonction fiable. Les équipes de sécurité doivent configurer l’accès de façon intentionnelle. Les dirigeants métier doivent définir les domaines où l’automatisation probabiliste est acceptable.

Les grilles structurées constituent le véritable mécanisme

Le mécanisme central est le passage de prompts ouverts à des grilles explicites assorties d’une incertitude structurée.

Un prompt destiné à un modèle généraliste peut demander : « Que devons-nous faire de ce dossier ? » La réponse peut être bien formulée, mais un autre système doit l’analyser. Le modèle peut aussi inventer une catégorie, modifier son format ou expliquer une décision sans produire un champ fiable.

Databricks ai_decide resserre l’interaction. Le développeur définit des questions nommées, des instructions et des critères autorisés. La fonction renvoie une structure de réponse prévisible que le SQL en aval peut adresser.

Cette contrainte réduit le travail d’intégration. Elle expose également le contrat de décision aux relecteurs. Un spécialiste de la conformité peut examiner la définition de l’escalade. Un responsable des opérations peut inspecter les descriptions des catégories. Un ingénieur data peut vérifier comment les probabilités deviennent des actions de workflow.

Le type choice illustre cette approche. Supposons qu’une organisation de support définisse l’expédition, la facturation et le support technique comme les seules étiquettes de routage. La fonction doit choisir parmi ces noms et renvoyer une probabilité pour chacun.

L’étiquette sélectionnée est utile, mais la distribution peut être plus informative. Un résultat partagé de près entre la facturation et le support technique signale une ambiguïté. Un workflow peut envoyer ce dossier vers une file générale au lieu de prétendre que l’étiquette principale est certaine.

Le type score utilise des critères ordonnés plutôt qu’un nombre libre. Une équipe peut définir trois niveaux d’urgence, allant d’une demande courante à un obstacle critique. Le score renvoyé est une moyenne pondérée par les probabilités des indices de critères.

Cette méthode préserve les informations sur les évaluations concurrentes. Si le modèle répartit la probabilité sur plusieurs niveaux, le résultat peut être fractionnaire. La sortie conserve également la légende et les probabilités à l’origine du score.

Plusieurs questions peuvent partager un même état. Cela réduit le besoin de faire passer les mêmes éléments de preuve dans des prompts distincts pour la catégorie, l’urgence, l’escalade et d’autres jugements. Cela conserve également les réponses liées ensemble.

Toutefois, le partage d’une entrée ne garantit pas que chaque question représente une évaluation indépendante. Les équipes doivent tester si les instructions interagissent de manière inattendue. Elles doivent aussi vérifier si la combinaison de questions modifie la qualité, la latence ou le coût pour leur charge de travail.

Databricks indique que le modèle sous-jacent peut changer si un autre modèle obtient de meilleurs résultats dans ses benchmarks internes. La documentation actuelle associe les modèles possibles à la licence Apache 2.0 et oriente les clients vers les conditions applicables aux modèles.

Le choix d’un modèle géré réduit la configuration. Il signifie également que le comportement de la fonction peut évoluer sous une interface SQL stable. Les métadonnées de version aident à identifier le contrat de la fonction, mais les équipes ont toujours besoin de tests de régression fondés sur des données représentatives.

C’est là que le mécanisme devient important sur le plan opérationnel. Une procédure stockée construite à partir de conditions déterministes peut être testée par rapport à des sorties exactes attendues. Une fonction probabiliste nécessite des vérifications de distribution, de seuils et des évaluations répétées.

Les équipes devraient maintenir des jeux d’évaluation étiquetés pour chaque grille importante. Ces jeux devraient inclure des exemples courants, des cas limites, des éléments de preuve manquants, des éléments de preuve contradictoires et des entrées qui doivent toujours être confiées à une personne.

Elles devraient également séparer la recommandation de l’exécution. Une fonction de décision peut prioriser une file de support avec des conséquences limitées. Le même niveau de confiance ne devrait pas autoriser automatiquement un remboursement, rejeter un candidat, suspendre un compte ou déclencher une réponse de sécurité.

L’interface SQL rend la composition facile. Une bonne conception de système doit garder les actions lourdes de conséquences volontairement difficiles.

Databricks ai_decide concurrence les appels de modèles généralistes et l’IA d’entrepôt de données

La principale concurrence oppose une fonction gérée, spécifique à une tâche, à la flexibilité consistant à construire une logique de décision autour d’un endpoint de modèle généraliste.

Databricks propose déjà ai_query, une fonction généraliste qui appelle un endpoint Model Serving. Les développeurs peuvent choisir un modèle pris en charge, rédiger leurs propres prompts et contrôler les paramètres ainsi que les types de retour.

La documentation ai_query recommande aux équipes de commencer par une AI Function spécifique à une tâche lorsqu’elle correspond à leur objectif. Elle positionne ai_query pour les cas nécessitant davantage de contrôle sur le modèle, le prompt, les paramètres ou la sortie.

Cette distinction crée un compromis clair.

Une fonction spécifique à une tâche réduit la configuration et impose un contrat structuré. Databricks gère le système qui sous-tend l’opération et peut en améliorer l’implémentation. Les équipes peuvent se concentrer sur leurs éléments de preuve, leurs questions et leurs critères.

Un appel de modèle généraliste offre davantage de flexibilité. Les développeurs peuvent utiliser un modèle personnalisé, ajuster les paramètres de décodage, définir un schéma différent, mettre en œuvre des endpoints de secours ou conserver une version fixe du modèle. Ils assument aussi davantage de travail d’ingénierie et d’évaluation.

Databricks ai_decide est le plus pertinent lorsqu’une décision s’inscrit dans ses trois formats disponibles. La probabilité, le choix nommé et le score ordonné couvrent de nombreuses tâches de routage et de priorisation. Ils ne couvrent pas toutes les structures de décision.

Une entreprise peut avoir besoin d’une classification multilabel, d’estimations numériques contraintes, de citations des éléments de preuve, d’exclusions fondées sur des règles ou d’une chaîne de questions dépendantes. Les développeurs peuvent encore avoir besoin de ai_query, de fonctions personnalisées ou d’une application externe dans ces cas.

Le paysage concurrentiel s’étend également au-delà de Databricks. Google Cloud documente une fonction AI.GENERATE_BOOL pour BigQuery qui renvoie un résultat booléen, des détails de réponse et des informations d’état. Elle peut traiter du texte et du contenu non structuré référencé via Gemini.

La fonction booléenne de Google prend en charge les paramètres de modèle et de requête. Sa documentation avertit également que la conception du prompt affecte les résultats et que la planification des requêtes peut amener l’inférence du modèle à traiter davantage de lignes que prévu.

Google propose séparément AI.IF, que sa documentation décrit comme prenant en charge l’optimisation des prompts et un mode optimisé. Ce mode peut entraîner un modèle distillé afin de réduire les coûts et la latence à grande échelle.

Databricks adopte une approche plus large, orientée rubriques, en un seul appel. Databricks ai_decide peut répondre à plusieurs questions et renvoyer des probabilités pour des choix nommés ou des scores ordonnés. La fonction booléenne documentée par Google se concentre sur la génération de réponses vrai ou faux, bien que BigQuery propose d’autres fonctions scalaires et génératives.

Aucune de ces approches n’élimine la conception applicative. L’IA native des entrepôts de données réduit la distance entre les données et l’inférence, mais les équipes doivent toujours choisir des seuils, matérialiser les entrées, contrôler les autorisations et évaluer les sorties.

La concurrence se jouera donc sur des preuves opérationnelles plutôt que sur la seule syntaxe. Les acheteurs doivent savoir comment les fonctions se comportent sur leurs enregistrements, dans leurs régions, selon leurs exigences de conformité et à un volume de production.

Une fonction qui réduit le travail d’intégration mais génère des coûts imprévisibles rencontrera des difficultés. Il en ira de même pour un endpoint flexible exigeant une équipe spécialisée pour chaque tâche de classification courante.

Databricks parie que de nombreuses décisions d’entreprise partagent suffisamment de structure pour mériter une primitive gérée. Le résultat dépendra de la capacité de ces primitives à rester compréhensibles lorsque les organisations les connecteront à des actions réelles.

Les décisions rapides exigent toujours une validation lente

L’étiquette bêta est l’avertissement le plus clair : Databricks a simplifié l’implémentation, mais n’a pas supprimé l’incertitude, les limites régionales ni la responsabilité humaine.

Databricks ai_decide est disponible en tant que fonctionnalité bêta. Les administrateurs d’espace de travail contrôlent l’accès via la page Previews, et la fonction n’est disponible que dans les régions prises en charge.

Elle ne fonctionne pas sur Databricks SQL Classic. La documentation exige Databricks Runtime 15.4 LTS ou version ultérieure et recommande Runtime 18.2 ou version ultérieure pour bénéficier des fonctionnalités et performances actuelles.

Ces prérequis limitent l’adoption immédiate. Les organisations utilisant des runtimes plus anciens, des entrepôts Classic, des régions non prises en charge ou des politiques strictes concernant les aperçus doivent modifier leur infrastructure ou attendre.

La couche de modèle introduit une autre incertitude. Databricks indique qu’il pourrait modifier le modèle sous-jacent lorsque ses benchmarks internes identifient une meilleure option. Cette évolution gérée peut améliorer les résultats, mais elle crée également une dérive du modèle du point de vue du client.

Un pipeline de décision ne peut pas s’appuyer uniquement sur la stabilité du nom de la fonction. Les équipes ont besoin d’évaluations de référence, de contrôles de publication, de seuils surveillés et de la capacité de comparer les résultats après des changements de plateforme.

La rubrique elle-même peut aussi échouer. Les instructions peuvent omettre une exception importante. Les catégories peuvent se chevaucher. Une échelle ordonnée peut suggérer une précision que les éléments de preuve ne permettent pas d’étayer.

La confiance exige une interprétation attentive. Un champ de confiance élevé indique dans quelle mesure l’état soutient l’évaluation selon le processus de la fonction. Il n’établit pas que la réponse est factuellement correcte ou équitable.

Les sorties de probabilité présentent un risque similaire. Une valeur de 0,9 semble précise, mais les utilisateurs ne doivent pas supposer que 90 % des prédictions comparables seront correctes sans preuve de calibration. La calibration doit être testée sur les propres cas étiquetés de l’organisation.

La qualité des données reste déterminante. Si l’état contient des enregistrements obsolètes, incomplets ou trompeurs, une rubrique bien structurée peut tout de même produire une mauvaise décision. Les contrôles de gouvernance déterminent qui peut utiliser les données ; ils ne garantissent pas que chaque entrée soit adaptée.

Les biais peuvent également être introduits par les exemples et les critères. La description d’une catégorie peut encoder les pratiques historiques d’une équipe, y compris ses angles morts. Un score peut reproduire des jugements humains incohérents issus d’un ensemble d’évaluation.

Les usages à fort impact nécessitent des garde-fous plus solides. Les décisions liées à l’emploi, au crédit, aux soins de santé, à l’assurance, au droit et à la sécurité impliquent des obligations qui dépassent la sortie d’un modèle. Les organisations devraient associer les équipes métier, juridiques, de sécurité et de gestion des risques avant d’automatiser des actions.

Même les flux de travail à moindre risque ont besoin d’une gestion des échecs. La fonction peut renvoyer une réponse nulle et un message d’erreur. Les pipelines doivent décider s’il faut réessayer, suspendre, utiliser une logique de secours déterministe ou orienter le cas vers une personne.

Selon la documentation, les réponses générées peuvent varier d’un appel à l’autre. Des évaluations répétées peuvent donc produire des étiquettes ou des scores différents pour des enregistrements à la limite. Les équipes ont besoin de politiques d’idempotence lorsque les actions en aval ne doivent se produire qu’une seule fois.

Le coût mérite une attention similaire. Chaque évaluation soutenue par un modèle consomme des ressources d’inférence. Poser plusieurs questions sur chaque ligne d’une grande table peut transformer une requête pratique en une opération coûteuse.

Les développeurs devraient isoler les lignes pertinentes avant d’appeler la fonction. Ils devraient matérialiser des ensembles d’entrée stables, empêcher toute réévaluation accidentelle de la table entière et stocker les sorties lorsque des inférences répétées n’apportent aucune valeur.

Aucune de ces préoccupations n’invalide l’orientation du produit. Elles expliquent pourquoi les décisions d’IA gouvernées exigent une norme différente de celle des résumés générés. Un résumé médiocre gêne un lecteur. Une mauvaise décision de routage ou de priorisation change ce qui se produit ensuite.

Trois signaux montreront si le pari fonctionne

Le prochain test consistera à déterminer si Databricks peut transformer une abstraction SQL prometteuse en une capacité de production mesurable et gouvernable.

Le premier signal est la performance d’évaluation documentée. Databricks n’a pas présenté de benchmarks indépendants établissant l’exactitude, la calibration, la latence ou le coût pour des tâches de décision représentatives. Les clients ont besoin de preuves spécifiques à leurs charges de travail plutôt que d’une promesse générale de rapidité.

Une validation utile comparerait Databricks ai_decide à ai_query, à des règles déterministes et à un examen humain établi. Elle devrait mesurer l’exactitude des étiquettes, la calibration des probabilités, la stabilité entre des appels répétés, le temps de traitement et le nombre de cas nécessitant une escalade.

Si les équipes peuvent publier des gains reproductibles avec des taux d’erreur contrôlés, l’approche spécifique à une tâche gagnera en crédibilité. Si elles doivent entourer chaque appel d’une logique corrective étendue, l’abstraction économise moins de travail que ne le suggère la syntaxe.

Le deuxième signal est une disponibilité en production plus large. La fonctionnalité porte actuellement l’étiquette bêta, exige l’activation des aperçus, exclut les entrepôts Databricks SQL Classic et ne prend en charge que certaines régions.

Une évolution vers une disponibilité plus large indiquerait que Databricks a confiance dans la fiabilité du service, la couverture de gouvernance et le support opérationnel. Des restrictions persistantes liées aux aperçus limiteraient la fonction aux expérimentations et aux flux de travail à faible risque.

La maturité de la gouvernance fait partie du même signal. Les administrateurs ont besoin de contrôles clairs sur les autorisations d’exécution, l’accès aux modèles, les pistes d’audit, le traitement régional et les changements apportés aux modèles sous-jacents. Ces contrôles doivent fonctionner de manière cohérente entre les plateformes cloud et les configurations d’espace de travail.

Le troisième signal est l’utilisation par les clients au-delà des démonstrations. La catégorisation de produits et le routage des tickets de support sont des exemples compréhensibles. Les preuves les plus solides viendront de flux de travail de production avec des seuils de revue publiés et des résultats commerciaux mesurables.

Surveillez les cas où les probabilités modifient le flux de travail, plutôt que de simplement décorer un tableau de bord. Une entreprise peut automatiser les décisions claires, envoyer les enregistrements ambigus à des spécialistes et utiliser les corrections obtenues pour tester sa rubrique.

Surveillez également les concurrents. Google Cloud expose déjà des fonctions génératives natives aux entrepôts de données, et d’autres plateformes de données continuent d’ajouter un accès aux modèles à proximité des données gouvernées. Une fonction concurrente offrant une calibration plus claire, une prise en charge des entrées plus large ou une charge opérationnelle moindre affaiblirait l’avantage de Databricks.

Databricks ai_decide illustre une évolution importante. Les entreprises ne se satisfont plus de modèles qui se contentent de décrire l’information. Elles veulent des systèmes qui aident à choisir, classer, router et escalader tout en restant dans des contrôles de données établis.

La prochaine étape prudente n’est pas de connecter directement la fonction à une action conséquente. Sélectionnez une file d’attente limitée, définissez une rubrique explicite et constituez un ensemble d’évaluation étiqueté. Comparez les sorties de la fonction aux décisions actuelles, puis choisissez des seuils pour l’automatisation et la revue humaine. Suivez séparément les erreurs, l’incertitude, la latence et la dérive.

Quelle décision dans votre organisation est suffisamment répétitive pour être évaluée, mais suffisamment réversible pour être testée en toute sécurité ? C’est le bon point de départ pour Databricks ai_decide. La valeur durable du produit viendra d’une discipline opérationnelle transparente, et non du traitement d’une sortie probabiliste comme une certitude.