14 août 2026

Utilisation d'AI_Functions dans votre entrepôt de données : principaux cas d'usage

Six cas d'usage de l'IA que vous pouvez exécuter en SQL pur, remplaçant ainsi les notebooks, les API et les pipelines que vous utilisez aujourd'hui.

par Srikant Das et Ismail Makhlouf

Dans la plupart des organisations, les data warehouses contiennent des données structurées, tandis que les données non structurées sont conservées dans le data lake. Cela fonctionne bien pour les charges de travail analytiques, qui consomment des données structurées à grande échelle, alimentant un ensemble connu de rapports jour après jour.

Les charges de travail d'AI, en revanche, nécessitent des entrées différentes. Les modèles d'AI doivent souvent analyser des données non structurées (comme des avis, des tickets d'assistance et des PDF) et les combiner avec des données structurées pour entraîner, concevoir et déployer des modèles. Ainsi, un analyste qui souhaite obtenir l'analyse des sentiments sur des tickets d'assistance doit envoyer les lignes vers un service externe, attendre les prédictions et les réintégrer manuellement dans un tableau. C'est lent, cela ne fonctionne plus en cas de modification de schéma, et cela introduit des risques inutiles en matière de sécurité et de gouvernance.

AI Functions résolvent ce problème en apportant l'AI directement à vos données, plutôt que de déplacer vos données vers un environnement d'AI distinct. Vous appelez les modèles au sein de requêtes SQL standards, ce qui permet de conserver l'ensemble du processus d'inférence dans vos pipelines existants et sous la gouvernance de Unity Catalog. Cette architecture change fondamentalement votre façon de travailler avec l'AI dans votre data warehouse :

La gouvernance par défaut : comme les AI Functions respectent les autorisations de Unity Catalog, vos données restent sécurisées et privées. Le modèle accède uniquement aux données que vous autorisez explicitement.
La simplicité native SQL : si vous savez écrire une instruction SELECT, vous pouvez créer des solutions avec l'AI. Databricks gère la complexité (planification, parallélisation et tentatives de réexécution) pour que vous n'ayez pas à vous soucier de la gestion des clusters ou de l'orchestration externe. Il est tout aussi simple d'exécuter une inférence sur des millions de lignes que sur une seule, la même requête s'adaptant sans réécriture.
Une facturation unifiée : éliminez la complexité liée au rapprochement de tableaux de bord disparates. L'utilisation de l'AI apparaît dans system.billing.usage aux côtés de vos coûts de warehouse Databricks SQL standards.
Des fonctions spécialisées : obtenez de meilleurs résultats à moindre coût. En utilisant des fonctions spécifiques à chaque tâche, telles que ai_classify, ai_extract, ai_translate et ai_parse_document, vous exploitez des modèles conçus pour des tâches précises plutôt que de payer trop cher pour une inférence à usage général.

Vous pouvez utiliser ces fonctions d'AI depuis n'importe quel endroit sur Databricks, y compris les notebooks, les Lakeflow Spark Declarative Pipelines et Workflow. Mais dans cet article, nous allons nous concentrer spécifiquement sur l'appel de ces fonctions depuis Databricks Lakehouse. Les cas d'usage ci-dessous vous montreront comment intégrer ces fonctions d'AI dans des charges de travail où vous devez combiner des données structurées de votre data warehouse avec des données non structurées, provenant soit de l'extérieur du data warehouse, soit générées par vous-même via des fonctions basées sur la GenAI.

Cas d'usage 1 : l'intelligence documentaire, des fichiers bruts aux lignes structurées

ai_parse_document sert de passerelle d'ingestion qui convertit le contenu des fichiers binaires bruts (comme les PDF ou les images) en texte lisible. Une fois l'analyse effectuée, ai_extract gère l'extraction granulaire de clés et de valeurs spécifiques. Cette approche combinée élimine le besoin de pipelines OCR personnalisés et fragiles ou de services d'analyse tiers qui cessent souvent de fonctionner lors des modifications de schéma.

Dans ce cas d'usage, nous pointons ai_parse_document vers un volume Databricks contenant des factures. Une fois ces factures analysées, un document d'analyse d'AI produit les résultats au format JSON, qui sont ensuite transmis à la fonction ai_extract, dans laquelle nous définissons les entités que nous souhaitons extraire de ces factures. Le résultat est un tableau structuré contenant les champs que nous voulions extraire des factures.

Le lignage s'étend désormais du PDF brut aux lignes extraites au sein d'un plan de requête unique. La passerelle que l'on crée habituellement à la main (un service OCR Python, un appel LLM et une étape d'aplatissement JSON) est entièrement intégrée à la requête.

Notebook de démonstration : intelligence documentaire

Cas d'usage 2 : analyse des sentiments sur les retours clients

La fonction ai_classify effectue une classification zero-shot, associant les commentaires en texte libre à un ensemble spécifique de labels définis par l'utilisateur, sans nécessiter d'entraînement de modèle. Ce processus transforme un texte non structuré et désordonné en colonnes gouvernées et interrogeables, rendant les données de sentiment et de sujet immédiatement disponibles pour les tableaux de bord BI et les rapports de direction.

Dans cet exemple, nous voulons classer les avis clients de la table bronze.nps_responses en catégories positive, négative, neutre et mixte.

Notebook de démonstration : analyse des sentiments

Cas d'usage 3 : traduction intégrée pour les données multilingues

Avec ai_translate, vous pouvez normaliser des données multilingues dans une seule langue cible directement au niveau de la couche de requête. Cela évite les silos de données et la fragmentation, permettant à toutes les analyses en aval (y compris la classification et l'extraction) de s'exécuter simultanément sur l'ensemble du jeu de données mondial plutôt que de traiter uniquement des segments en anglais.

Dans cet exemple, nous extrayons le sentiment de différents avis clients, puis nous les traduisons en anglais.

Notebook de démonstration : traduction et normalisation

Cas d'usage 4 : classification et routage à grande échelle

Axé sur l'efficacité opérationnelle, ai_classify convertit les entrées de forme libre telles que les tickets d'assistance ou les transcriptions d'appels en catégories exploitables. En identifiant l'intention et l'urgence des commentaires entrants dès l'ingestion, il permet un routage automatisé et intelligent vers les équipes appropriées ou des systèmes de réponse automatisés.

Dans le cas d'usage ci-dessous, nous ingérons différents tickets d'assistance à partir d'une table, puis nous utilisons ai_classify pour déterminer l'intention de l'utilisateur et l'urgence du ticket.

Notebook de démonstration : classification et routage

Cas d'usage 5 : Extraction structurée d'appels commerciaux avec ai_extract

La fonction ai_extract est conçue pour extraire des informations semi-structurées à partir de contenus longs, comme les transcriptions d'appels commerciaux, et convertir le texte narratif en champs structurés distincts. Cela apporte une valeur significative en intégrant directement des informations qualitatives dans les outils de BI, transformant ainsi les conversations orales en métriques interrogeables telles que l'étape de la vente et les indicateurs de risque.

Dans ce cas d'usage, nous analysons une longue transcription pour identifier la prochaine étape, l'étape de la vente, l'indicateur de risque et le motif du risque, afin que les commerciaux puissent donner suite aux résultats de la réunion qui a généré cette transcription.

Notebook de démonstration : Extraction d'appels commerciaux

Cas d'usage 6 : Rédaction générative avec ai_query

ai_query est la fonction la plus générale et la base de toutes les autres : elle vous permet d'envoyer un prompt à n'importe quel point de terminaison de modèle de fondation hébergé par Databricks auquel vous avez accès, et elle renverra la réponse du modèle pour chaque ligne.

Dans ce cas d'usage, nous pouvons utiliser ai_query pour rédiger un e-mail de relance de renouvellement pour chaque compte client dans la table fictive gold.renewal_signals qui nous indique quels comptes sont prêts pour un renouvellement.

Comme vous rédigez vous-même le prompt, il peut faire tout ce que le modèle est capable de faire, c'est pourquoi il gère les cas que les fonctions plus spécifiques ne couvrent pas.

Notebook de démonstration : Rédaction générative

Conseils de pro pour la production

Étiquetez vos jobs dès le premier jour : cela vous permettra d'attribuer le coût des fonctions IA aux bons jobs
Essayez d'abord la fonction spécifique à la tâche : utilisez ai_query uniquement si aucune des fonctions ai_classify, ai_extract, ai_parse_document ou ai_translate ne convient
Demandez un résultat structuré : pour ai_query, utilisez responseFormat pour obtenir un résultat structuré. Si vous passez un schéma DDL STRUCT, vous obtenez des champs typés au lieu de chaînes brutes ; les formats JSON-schema/json_object renvoient toujours des chaînes JSON.
Soyez réfléchi dans le choix du modèle : chaque modèle de fondation présente des compromis, notamment en termes de coût, de performance et de formats d'entrée pris en charge. Veillez à choisir sciemment le modèle adapté à chaque cas d'usage
Faites un test sur un échantillon avant de passer à l'échelle : exécutez le traitement sur au moins 10 000 lignes, lisez le résultat, puis lancez le reste. Le compromis coût-précision est propre à chaque cas d'usage.
Traitez les prompts comme du code : versionnez-les, passez-les en revue dans des pull requests, commentez-les. Dans ce flux de travail, un prompt est une transformation qui contient de la logique métier

Ce que cela signifie pour votre stratégie de data warehouse

Le fil conducteur de ces six cas d'usage est le même. L'IA s'exécute au même endroit que le reste du data warehouse : une seule plateforme, un seul modèle de gouvernance, une seule facture, un seul ensemble de pipelines. N'importe quelle ligne de votre ETL SQL existant peut intégrer une étape d'IA sans que vous ayez à déployer un système pour l'héberger, et chaque script Python qui servait auparavant à traduire, scorer ou classifier des données en parallèle devient candidat à un remplacement en une seule ligne.

Commencez donc par une seule colonne. Prenez la charge de travail où le service actuel est le plus fragile, réécrivez-la sous forme de SELECT, exécutez-la sur 10 000 lignes et lisez le résultat. Après un court sprint, vous saurez si cela convient, et vous aurez cessé de payer les frais supplémentaires liés au transfert de données à l'extérieur juste pour pouvoir les utiliser.

Notebooks de démonstration

Chaque notebook est fourni avec des exemples de données intégrés, les étapes SQL pas à pas et le résultat attendu.