Présentation de l'agent d'ingénierie des données

L'agent Data Engineering vous permet de créer, de modifier et de résoudre les problèmes liés aux pipelines de données dans BigQuery à l'aide de requêtes en langage naturel. L'agent Data Engineering offre les fonctionnalités suivantes pour simplifier vos workflows d'ingénierie des données afin d'ingérer des données dans BigQuery :

  • Intégration de Dataform : l'agent génère et organise le code du pipeline de données directement dans les dépôts et espaces de travail Dataform.
  • Génération de plans : l'agent peut résumer sa réflexion et générer un plan que vous pouvez examiner et vérifier avant de continuer.
  • Validation du code : l'agent valide et corrige automatiquement les erreurs de compilation de tout code généré pour s'assurer que le pipeline de données est fonctionnel.
  • Data wrangling automatique : l'agent effectue le data wrangling et transforme les données brutes en tableaux structurés sans intervention manuelle.
  • Instructions personnalisées : l'agent accepte les instructions personnalisées qui vous permettent de définir des règles spécifiques et des consignes réutilisables en langage naturel.
  • Contexte externe : l'agent est intégré à Knowledge Catalog pour obtenir un contexte supplémentaire.
  • Contrôle du pipeline : vous pouvez examiner et personnaliser les plans d'agent générés avant l'exécution de toute action.
  • Optimisation : l'agent peut optimiser les performances de votre pipeline de données.
  • Résoudre les problèmes et réparer : l'agent peut résoudre les échecs de pipeline et corriger son code.
  • Recommandations interactives : l'agent fournit des recommandations interactives et contextuelles au début et tout au long de la session.
  • Enrichissement des métadonnées Knowledge Catalog : l'agent peut générer automatiquement des métadonnées Knowledge Catalog à partir de vos configurations de tables et les envoyer à Knowledge Catalog lors de l'exécution du pipeline.

Où utiliser l'agent Data Engineering

Vous pouvez utiliser l'agent Data Engineering avec les méthodes suivantes :

Comment l'agent Data Engineering utilise vos données

Pour générer des réponses d'agent de meilleure qualité, l'agent Data Engineering peut récupérer des données et des métadonnées supplémentaires à partir de BigQuery et de Knowledge Catalog, y compris des exemples de lignes de tables BigQuery et des profils d'analyse de données générés dans Knowledge Catalog. L'agent n'utilise pas ces données pour l'entraînement. Il ne les utilise que comme contexte supplémentaire lors des conversations avec l'agent pour éclairer ses réponses.

Où l'agent Data Engineering traite vos données

Pour en savoir plus sur les emplacements où l'agent Data Engineering traite vos données, consultez Où Gemini dans BigQuery traite-t-il vos données ?.

Limites

L'agent Data Engineering présente les limites suivantes :

  • L'agent Data Engineering n'accepte pas les commandes en langage naturel pour les types de fichiers suivants :
    • Notebooks
    • Préparation des données
  • L'agent Data Engineering ne peut pas exécuter de pipelines. Vous devez examiner, exécuter ou planifier les pipelines.
  • L'agent Data Engineering ne peut pas rechercher de liens Web ni d'URL fournis dans les instructions ou les requêtes directes.
  • Lorsque vous importez des fichiers dans un fichier d'instructions de l'agent, la syntaxe d'importation @ n'accepte que les chemins d'accès qui commencent par ./, / ou une lettre.
  • La fonctionnalité Aperçu des données n'est compatible qu'avec les tables, les déclarations ou les requêtes dont l'indicateur hasOutput est défini sur true.
  • Le Data Engineering Agent est soumis aux limitations générales de la technologie d'IA.
  • Lorsque vous créez des pipelines sur des tables externes Apache Iceberg gérées par le catalogue Lakehouse Runtime (anciennement BigLake Metastore), toutes les limites du catalogue Lakehouse Runtime s'appliquent. Plus précisément, l'agent ne peut pas générer de mutations d'écriture (telles que INSERT, UPDATE, DELETE ou MERGE) ni d'instructions LDD (telles que CREATE TABLE ou DROP TABLE) sur les tables Iceberg. Pour en savoir plus, consultez Concepts des points de terminaison du catalogue REST Apache Iceberg.

Fonctionnalités et personnalisations de l'agent

Les sections suivantes décrivent des fonctionnalités d'agent supplémentaires et d'autres méthodes permettant de personnaliser l'agent Data Engineering.

Instructions pour l'agent

Les instructions de l'agent sont des instructions en langage naturel destinées à l'agent Data Engineering. Elles vous permettent de stocker des instructions persistantes afin que l'agent suive un ensemble de règles personnalisées prédéfinies. Utilisez des instructions pour l'agent si vous souhaitez que les résultats de l'agent soient cohérents dans toute votre organisation (par exemple, avec des conventions de dénomination ou pour appliquer un guide de style).

Pour créer des instructions d'agent pour l'agent Data Engineering, créez un fichier de contexte GEMINI.MD en tant que fichier d'instructions d'agent.

Bonnes pratiques concernant les fichiers d'instructions pour les agents

Lorsque vous utilisez des instructions pour l'agent, nous vous recommandons de suivre les conseils suivants :

  • Tous les chemins d'accès aux fichiers dans Dataform sont relatifs à la racine du dépôt. Utilisez des chemins relatifs pour toute syntaxe @file.md afin d'importer correctement les instructions vers GEMINI.md.
  • Les fichiers importés dans GEMINI.md peuvent eux-mêmes contenir des importations, ce qui peut créer une structure imbriquée. Pour éviter une récursion infinie, GEMINI.md est limité à une profondeur d'importation maximale de cinq niveaux.
  • Pour partager des instructions entre les pipelines de données, stockez-les dans un dépôt Dataform central et associez-les au dépôt Dataform de travail. Vous pouvez utiliser des instructions locales pour remplacer les règles centrales pour un comportement spécifique au pipeline.
  • Pour assurer la cohérence de votre projet, vous pouvez créer des liens vers des fichiers de conventions de dénomination ou des guides de style, et demander à l'agent de suivre ces consignes lorsqu'il travaille avec vos pipelines de données.
  • Vous pouvez suggérer des calques de données dans le fichier d'instructions pour regrouper différents types de données.
  • L'utilisation de titres et de listes dans le fichier d'instructions de l'agent peut aider à organiser et à clarifier les instructions pour l'agent Data Engineering.
  • Fournissez des noms de fichiers pertinents et regroupez les instructions similaires dans un fichier. Organisez les règles de manière logique par catégorie, fonctionnalité ou fonction à l'aide de titres Markdown.
  • Pour éviter toute instruction contradictoire, définissez clairement les conditions spécifiques dans lesquelles chaque instruction s'applique.
  • Itérez et affinez vos requêtes et votre workflow. Le comportement des agents évolue au fil du temps avec les déploiements d'agents et les mises à niveau de modèles. Nous vous recommandons donc d'itérer sur vos règles avec différentes requêtes pour identifier les points à améliorer. Synchronisez votre fichier de règles avec les modifications apportées à votre pipeline de données.

L'exemple suivant montre un fichier d'instructions d'agent nommé GEMINI.md qui utilise nos bonnes pratiques pour une utilisation efficace de l'agent Data Engineering :

  ### Naming Conventions

  * Datasets: [business_domain]_[use_case] (e.g., ecommerce_sales)

  * Tables:
      - Raw/External: raw_[source_name]
      - Staging: stg_[business_entity]
      - Dimension: dim_[dimension_name]
      - Fact: fct_[fact_name]

  * Dataform Folders:
      - sources
      - staging
      - marts
      - dataProducts

  * Views: vw_[view_name]

  * Columns: snake_case (e.g., order_id, customer_name)

  ## Cloud Storage data load
  * When ingesting data from Cloud Storage, create external tables.

  ## Null handling
  * Filter out null id values

  ## String normalization
  * Standardize string columns by converting to lower case

  ## Data Cleaning Guidelines
  @./generic_cleaning.md

Importer des fichiers locaux supplémentaires en tant qu'instructions pour l'agent

Vous pouvez également importer d'autres fichiers d'instructions pour l'agent Data Engineering dans le fichier GEMINI.md avec la syntaxe @file.md. Pour en savoir plus, consultez Processeur d'importation de mémoire.

Nettoyage automatique des données

Vous pouvez utiliser l'agent Data Engineering pour transformer des données brutes non traitées en tables structurées adaptées à l'analyse des données. Lorsqu'il est invité à le faire, l'agent échantillonne d'abord jusqu'à 1 000 000 d'enregistrements de chaque table standard ou externe. L'agent effectue ensuite une analyse approfondie des données en exécutant des requêtes de profilage sur cet échantillon. Après avoir généré des transformations de données, l'agent répète ce processus d'échantillonnage et de profilage pour évaluer la qualité des transformations. Ces transformations de data wrangling peuvent inclure la correction des incohérences, des valeurs aberrantes ou des incompatibilités de type. L'agent Data Engineering crée ensuite un plan qui décrit les étapes de préparation proposées. Vous pouvez l'examiner et l'affiner avant toute action.

L'agent Data Engineering lance également l'analyse de data wrangling chaque fois que vous ajoutez un tableau brut, tel qu'un tableau externe basé sur un fichier CSV. Vous pouvez examiner le plan de préparation des données et l'ajuster à l'aide de commandes conversationnelles.

L'échantillonnage de données et le profilage utilisent des ressources BigQuery et sont soumis aux tarifs de BigQuery.

L'agent Data Engineering est compatible avec les transformations de data wrangling suivantes :

  • Nettoyage des données. L'agent peut analyser les données brutes et suggérer des opportunités de nettoyage, comme la suppression des valeurs aberrantes, le remplissage des valeurs manquantes ou incohérentes (imputation de données), la correction des données en double ou la standardisation des formats de données (par exemple, les numéros de téléphone ou les adresses).
  • Transformations structurelles Lorsqu'un schéma cible est fourni, l'agent peut annuler l'imbrication ou extraire des valeurs des types JSON, ARRAY ou STRUCT, fusionner plusieurs colonnes en une seule ou fractionner une colonne en plusieurs colonnes.
  • Détection et conversion des types de données. L'agent peut analyser les données pour déterminer les types de champs appropriés. L'agent peut ensuite effectuer un transtypage sécurisé pour résoudre les incohérences de mise en forme dans les champs de date, d'heure, de date et heure, ou de code temporel.
  • Conversions d'unités L'agent peut convertir automatiquement différentes unités d'un champ en une seule unité cohérente pour normaliser vos données.

Pour garantir l'exactitude, l'agent utilise des échantillons représentatifs de vos données pour détecter les problèmes et valider sa logique de transformation.

Générer et examiner des plans d'agent

L'agent d'ingénierie des données peut générer des plans d'agent qui fournissent un résumé et une présentation des objectifs et des étapes à suivre pour répondre à une demande. Lorsque vous demandez à l'agent d'effectuer des requêtes complexes nécessitant de nombreuses modifications, nous vous recommandons de lui demander de vous fournir un plan d'agent afin que vous puissiez examiner ses intentions avant qu'il n'agisse. Un forfait Agent d'ingénierie des données comprend généralement les éléments suivants :

  • Objectif de l'agent pour une demande spécifique
  • Aperçu général des étapes que l'agent prévoit de suivre
  • Toutes les hypothèses formulées par l'agent
  • Fichiers que l'agent prévoit de modifier
  • Toutes les étapes d'optimisation ou de nettoyage qu'il prévoit d'effectuer
  • Un plan d'exécution par étapes

Dans votre requête, vous pouvez inclure la nécessité d'examiner et d'approuver le plan afin que l'agent n'effectue aucune action sans votre approbation explicite. Exemple :

Create a plan for a pipeline that finds the
top N pick up and drop off locations in NYC. I want to review the plan and
approve it before you create the pipeline.

L'agent peut également générer automatiquement un plan d'agent et vous demander de l'approuver. Ce résultat peut se produire lorsqu'une requête est trop ambiguë ou si l'agent a besoin de plus de clarté pour répondre à votre demande.

Pour connaître les bonnes pratiques concernant l'utilisation des forfaits d'agent, consultez Bonnes pratiques.

Ajouter un contexte depuis Knowledge Catalog

L'agent Data Engineering utilise Knowledge Catalog en associant des termes de glossaire aux tables et colonnes BigQuery, et en générant des analyses de profil de données. Les termes du glossaire peuvent taguer les colonnes qui nécessitent un contexte supplémentaire, comme les colonnes contenant des informations permettant d'identifier personnellement l'utilisateur et qui nécessitent des instructions de traitement spécifiques, ou pour identifier les colonnes correspondantes avec des noms différents dans les tables.

Knowledge Catalog utilise également le profilage des données, qui permet à l'agent de mieux comprendre la distribution des données dans les colonnes des tableaux et de créer des assertions de qualité des données plus spécifiques.

L'agent peut également utiliser Knowledge Catalog pour découvrir et interroger des tables Apache Iceberg. Pour en savoir plus, consultez Créer des pipelines sur des tables Apache Iceberg.

Ajouter des vérifications de la qualité des données à une table existante

Lorsque vous demandez à l'agent d'ajouter des contrôles de qualité, il déduit des contrôles raisonnables pour le tableau en fonction du schéma et des exemples. Vous pouvez également ajouter des affirmations subjectives dans la requête. Exemple :

  Add data quality checks for bigquery-public-data.thelook_ecommerce.users.

Lors de l'exécution du pipeline, les résultats de toutes les assertions Dataform sont automatiquement publiés dans Knowledge Catalog (aperçu). Ces résultats remplissent le tableau de bord sur la qualité des données de Knowledge Catalog avec un état de réussite ou d'échec. Chaque exécution écrase les tableaux de données sur la qualité des données existants publiés par les exécutions Dataform précédentes, mais n'affecte pas les tableaux de données créés par les analyses de données Knowledge Catalog.

Enrichissement automatique des données

Les métadonnées standards de BigQuery (ensembles de données, tables et vues, par exemple) sont automatiquement disponibles dans Knowledge Catalog.

Vous pouvez également définir des métadonnées personnalisées pour vos tables et vues directement dans le bloc de configuration de vos fichiers .sqlx. Une fois une action effectuée, Dataform lance automatiquement une synchronisation des métadonnées avec Knowledge Catalog. Ce processus d'enrichissement met à jour le Knowledge Catalog avec les métadonnées sémantiques définies dans votre configuration SQLX.

Utilisez la clé de métadonnées pour spécifier des informations pour le Knowledge Catalog. Le processus d'enrichissement est compatible avec les constructions de métadonnées suivantes :

  • Présentation : documentation et texte récapitulatif pour l'entrée. Nécessite la version 3.0.37 ou ultérieure de Dataform Core.
  • Aspects génériques : détails sémantiques tels que le système de table et les informations sur le type. Nécessite la version 3.0.52 ou ultérieure de Dataform Core.

L'exemple de configuration suivant montre comment ajouter une vue d'ensemble et des aspects de métadonnées génériques à une configuration de table pour Knowledge Catalog :

config {
  type: "table",
  metadata: {
    overview: "This table provides standardized trip data.",
    extraProperties: {
        generic: {
              system: "BigQuery",
              type: "table"
        }
      }
  }
}

Pour vérifier l'état d'une mise à jour des métadonnées, consultez Inspecter les journaux d'exécution de l'espace de travail pour les workflows Dataform ou Afficher les exécutions manuelles passées pour les pipelines BigQuery.

Pour vérifier les métadonnées synchronisées, vous pouvez rechercher le composant dans Knowledge Catalog. Pour en savoir plus, consultez Rechercher des ressources.

Optimisez les pipelines de données

Vous pouvez demander à l'agent d'optimiser vos pipelines de données. Lorsque vous générez le langage LDD pour de nouvelles tables, l'agent Data Engineering recommande le partitionnement et le clustering en fonction des modèles de consommation des données analysés. De plus, l'agent peut appliquer automatiquement d'autres optimisations de pipeline. Voici quelques exemples d'optimisations possibles :

  • Élimination des colonnes pour réduire les données lues à partir du stockage, afin d'agir comme principal moteur de coûts et de performances.
  • Le pushdown de prédicats permet de filtrer les données en amont dans le plan d'exécution afin de réduire considérablement le volume traité par les opérations suivantes.
  • Élimination des sous-expressions courantes pour améliorer l'efficacité en identifiant et en calculant la logique de transformation partagée une seule fois, ce qui évite les pratiques inefficaces telles que l'analyse et la jointure de grandes tables plusieurs fois.
  • Des modèles incrémentiels pour traiter uniquement les données nouvelles ou modifiées depuis la dernière exécution au lieu de régénérer des tables entières à chaque exécution.

Créer des pipelines sur des tables Apache Iceberg

L'agent Data Engineering permet de générer et de compiler des pipelines Dataform sur des tables Apache Iceberg gérées par le catalogue du runtime Lakehouse (anciennement BigLake Metastore). Cette fonctionnalité vous permet d'interroger et de joindre des tables régionales au format Open Source (stockées dans Cloud Storage) directement à vos tables BigQuery. Pour en savoir plus, consultez Concepts des points de terminaison du catalogue REST Apache Iceberg.

Par exemple, vous pouvez demander à l'agent d'interroger une table Apache Iceberg dans le catalogue d'exécution Lakehouse :

Include the stackoverflow_post_history_iceberg table in this pipeline.

Dans vos requêtes, vous n'avez pas besoin de spécifier des chemins complets en quatre parties (par exemple, project.catalog.dataset.table). Vous pouvez faire référence aux tables Apache Iceberg en utilisant des noms standards en langage naturel ou des identifiants logiques (par exemple, the StackOverflow post history table ou post_history). L'agent appelle automatiquement les recherches dans le catalogue sémantique à l'aide de Knowledge Catalog pour résoudre et associer les tables Apache Iceberg appropriées à l'espace de travail de votre pipeline.

Pour utiliser cette fonctionnalité, votre dépôt Dataform doit utiliser Dataform Core version 3.0.33 ou ultérieure.

Recommandations interactives

L'agent Data Engineering analyse l'état de compilation de votre espace de travail, l'historique d'exécution et l'état de la conversation active pour vous fournir des recommandations pratiques directement dans l'interface de chat. Ces suggestions s'affichent automatiquement lorsque vous ouvrez un espace de travail et tout au long de la session. Elles vous aident à configurer votre espace de travail, à résoudre les problèmes et à optimiser votre workflow.

Pour utiliser une recommandation, cliquez sur l'une des suggestions sous Recommandations de l'IA. La requête est alors chargée dans la barre de saisie du chat. Vous pouvez la modifier ou la personnaliser avant de l'envoyer à l'agent. Vous pouvez également pointer sur une suggestion pour afficher le prompt exact.

Bonnes pratiques

Pour améliorer les résultats lorsque vous travaillez avec l'agent Data Engineering et Dataform, nous vous recommandons de procéder comme suit :

Utilisez les instructions de l'agent pour les demandes courantes. Si vous appliquez souvent certaines techniques ou si vous apportez fréquemment les mêmes corrections à l'agent, utilisez les instructions de l'agent comme emplacement centralisé pour stocker les instructions et les demandes courantes.

Utilisez des plans d'agent. Les plans d'agent peuvent être utiles pour décomposer les tâches complexes du pipeline. Les plans de l'agent peuvent également vous montrer les hypothèses et les intentions de l'agent. Nous vous recommandons donc de les examiner pour vous assurer que l'agent dispose du contexte approprié.

Après avoir examiné un plan, vous pouvez le modifier en fournissant des commentaires et des modifications à l'agent Data Engineering. Exemple :

In the plan, ensure that all of the intermediate tables are views.

Dans certains cas, il peut être utile de demander à l'agent de générer un plan qui n'a pas besoin de votre approbation explicite. Le fait de demander à l'agent de planifier ses actions l'oblige à les décomposer, ce qui conduit souvent à de meilleurs résultats. Vous pouvez forcer l'agent à générer un plan et à l'exécuter automatiquement. Exemple :

Create a plan for a pipeline that finds the
top N pick up and drop off locations in NYC. You have my explicit pre-approval
to go ahead and execute this plan.

Écrivez de manière claire. Énoncez votre demande clairement et évitez d'être vague. Dans la mesure du possible, fournissez des sources de données source et de destination lorsque vous posez une question, comme dans l'exemple suivant :

  Extract data from the sales.customers table in the us_west_1 region, and load
  it into the reporting.dim_customers table in BigQuery. Match the schema of the
  destination table.

Formulez des demandes directes et ciblées. Posez une question à la fois et rédigez des requêtes concises. Pour les requêtes comportant plusieurs questions, détaillez chaque partie distincte de la question pour plus de clarté, comme dans l'exemple suivant :

  1. Create a new table named staging.events_cleaned. Use raw.events as the
     source. This new table should filter out any records where the user_agent
     matches the pattern '%bot%'. All original columns should be included.

  2. Next, create a table named analytics.user_sessions. Use
     staging.events_cleaned as the source. This table should calculate the
     duration for each session by grouping by session_id and finding the
     difference between the MAX(event_timestamp) and MIN(event_timestamp).

Donnez des instructions explicites et mettez en avant les termes clés. Vous pouvez mettre l'accent sur des termes ou des concepts clés dans vos requêtes et indiquer que certaines exigences sont importantes, comme dans l'exemple suivant :

  When creating the staging.customers table, it is *VERY IMPORTANT* that you
  transform the email column from the source table bronze.raw_customers.
  Coalesce any NULL values in the email column to an empty string ''.

Spécifiez l'ordre des opérations. Pour les tâches ordonnées, structurez votre requête sous forme de listes, où les éléments listés sont divisés en petites étapes ciblées, comme indiqué dans l'exemple suivant :

  Create a pipeline with the following steps:
  1. Extract data from the ecomm.orders table.
  2. Join the extracted data with the marts.customers table on customer_id.
  3. Load the final result into the reporting.customer_orders table.

Affinez et itérez. Essayez différentes expressions et approches pour voir ce qui donne les meilleurs résultats. Si l'agent génère du code SQL non valide ou commet d'autres erreurs, guidez-le à l'aide d'exemples ou de documentation publique.

  The previous query was incorrect because it removed the timestamp. Please
  correct the SQL. Use the TIMESTAMP_TRUNC function to truncate the
  event_timestamp to the nearest hour, instead of casting it as a DATE. For
  example: TIMESTAMP_TRUNC(event_timestamp, HOUR).

Évaluer les pipelines de données

Pour évaluer l'efficacité d'un pipeline de données généré par l'agent d'ingénierie des données, utilisez l'outil EvalBench. EvalBench est un framework Open Source qui permet d'effectuer des évaluations agentiques multitours. EvalBench agit comme une suite de tests unitaires automatisée. Il vous permet de configurer des scénarios multitours, d'ajouter des évaluateurs déterministes et basés sur des LLM, et de gérer le cycle de vie de vos pipelines Dataform.

En simulant des requêtes en langage naturel dans un bac à sable isolé, EvalBench mesure l'efficacité avec laquelle l'agent comprend les instructions, appelle les bons outils et génère le code de pipeline approprié. EvalBench peut vérifier vos pipelines de données en procédant comme suit :

  • Valider les règles personnalisées : vérifiez que l'agent respecte scrupuleusement les consignes de codage, les conventions de dénomination et les bonnes pratiques spécifiques à votre organisation.
  • Éviter les régressions de code : testez les modifications du pipeline avant le déploiement pour vous assurer que les mises à jour de l'agent ou les modifications du schéma ne compromettent pas les fonctionnalités existantes.
  • Générez des benchmarks de qualité : obtenez des scores objectifs et automatisés pour l'exactitude du code SQL, la précision de l'exécution des outils et la fiabilité des pipelines.

Exécuter une évaluation de pipeline de données

Vous pouvez exécuter EvalBench de deux manières :

  • Bac à sable dynamique : EvalBench provisionne un dépôt et un espace de travail Dataform temporaires et vierges au début d'une exécution d'évaluation, exécute les scénarios de test et supprime automatiquement toutes les ressources créées à la fin. Ce mode ne modifie aucun code de production, aucun dépôt de production ni aucun ensemble de données BigQuery, et ne laisse aucun artefact dans votre projet Google Cloud . Le mode bac à sable dynamique convient aux pipelines CI/CD automatisés, aux tests de régression nocturnes et à la notation objective des benchmarks où une isolation stricte de l'environnement est requise.

  • Espace de travail statique : EvalBench se connecte à un dépôt et à un espace de travail Dataform préexistants gérés par l'utilisateur, et ignore les scripts de création et de suppression automatiques. Ce mode permet à l'agent en cours d'évaluation de modifier et de créer des fichiers SQLX dans l'espace de travail existant lorsqu'il traite des cas d'évaluation. Le mode espace de travail statique convient à l'ingénierie de requêtes active, à l'itération de rubriques et au débogage local où vous devez inspecter les fichiers SQLX générés directement dans votre espace de travail Dataform après l'exécution.

Avant de commencer

Pour obtenir les autorisations nécessaires pour exécuter EvalBench, demandez à votre administrateur de vous accorder les rôles IAM suivants sur le compte de service ou l'identité utilisateur exécutant EvalBench :

Pour en savoir plus sur l'attribution de rôles, consultez Gérer l'accès aux projets, aux dossiers et aux organisations.

Vous pouvez également obtenir les autorisations requises avec des rôles personnalisés ou d'autres rôles prédéfinis.

Exécuter une évaluation dans un bac à sable dynamique

Pour évaluer votre pipeline de données en mode bac à sable dynamique, procédez comme suit :

  1. Suivez la procédure pour cloner le dépôt, configurer l'environnement virtuel et installer les dépendances EvalBench. Pour en savoir plus, consultez Premiers pas.
  2. Dans le répertoire datasets/dea-tools/, vérifiez que le fichier de configuration d'exécution de l'exemple (example_run_config.yaml) inclut les lignes suivantes :

    set_up_script: datasets/dea-tools/scripts/setup_dataform.sh
    tear_down_script: datasets/dea-tools/scripts/teardown_dataform.sh
  3. Exécutez EvalBench avec la commande suivante :

    EVAL_GCP_PROJECT_ID=PROJECT_ID \
    EVAL_GCP_PROJECT_REGION=REGION \
    .venv/bin/python3 evalbench/evalbench.py --experiment_config=datasets/dea-tools/example_run_config.yaml

    Remplacez les éléments suivants :

    • PROJECT_ID : ID du projet Google Cloud.
    • REGION : région du projet Google Cloud.

Exécuter une évaluation dans un espace de travail d'évaluation statique

Pour évaluer votre pipeline de données en mode espace de travail statique, procédez comme suit :

  1. Suivez les étapes pour cloner le dépôt, configurer l'environnement virtuel et installer les dépendances. Pour en savoir plus, consultez Premiers pas.
  2. Dans le répertoire datasets/dea-tools/, modifiez le fichier de configuration d'exécution de l'exemple (example_run_config.yaml) pour mettre en commentaire les lignes set_up_script et tear_down_script, et ajoutez les configurations dataform_repository et dataform_workspace :

    ...
    # set_up_script: datasets/dea-tools/scripts/setup_dataform.sh
    # tear_down_script: datasets/dea-tools/scripts/teardown_dataform.sh
    dataform_repository: !ENV ${EVAL_DEA_REPOSITORY_ID}
    dataform_workspace: !ENV ${EVAL_DEA_WORKSPACE_ID}
    ...
  3. Exécutez EvalBench avec la commande suivante :

    EVAL_GCP_PROJECT_ID=PROJECT_ID \
    EVAL_GCP_PROJECT_REGION=REGION \
      EVAL_DEA_REPOSITORY_ID=REPOSITORY_ID \
      EVAL_DEA_WORKSPACE_ID=WORKSPACE_ID \
      .venv/bin/python3 evalbench/evalbench.py --experiment_config=datasets/dea-tools/example_run_config.yaml

    Remplacez les éléments suivants :

    • PROJECT_ID : ID du projet Google Cloud.
    • REGION : région du projet Google Cloud.
    • REPOSITORY_ID : ID du dépôt contenant le pipeline de données.
    • WORKSPACE_ID : ID de l'espace de travail contenant le pipeline de données.
  4. Facultatif : Vous pouvez également exécuter EvalBench avec core_10_cases_suite.yaml pour tester le pipeline de données par rapport à 10 cas d'évaluation de base de manière séquentielle avec isolation de l'environnement en créant un dépôt pour chaque cas de test. Pour ce faire, exécutez la commande suivante :

    EVAL_GCP_PROJECT_ID=PROJECT_ID \
    EVAL_GCP_PROJECT_REGION=REGION \
    .venv/bin/python3 evalbench/evalbench.py --suite_config=datasets/dea-tools/core_10_cases_suite.yaml

Bonnes pratiques pour évaluer les pipelines de données

Pour améliorer les performances et la justesse des évaluations de votre pipeline de données à l'aide d'EvalBench, nous vous recommandons de procéder comme suit :

  • Recherchez l'appel du workflow Dataform et les ID de job BigQuery dans les journaux d'évaluation. Utilisez ces ID pour faire des références croisées et inspecter les artefacts d'exécution générés, les résultats de compilation et les journaux de requêtes dans la console Google Cloud .
  • Exécutez toujours la suite d'évaluation principale (--suite_config) avant de publier des modifications de modèle ou d'invite pour assurer une couverture complète de la régression dans divers scénarios d'ingénierie des données.
  • Utilisez EVAL_DATAFORM_SETUP_ENV_FILES_DIR pour précharger les fichiers de configuration de l'environnement, tels que workflow_settings.yaml et les définitions de schéma de base, dans l'espace de travail de test. Ces fichiers de configuration garantissent que l'agent s'appuie sur des environnements existants réalistes plutôt que sur des espaces de travail vides.
  • Lorsque vous résolvez des problèmes d'échec d'évaluation en mode bac à sable dynamique, commentez tear_down_script dans votre configuration d'exécution pour conserver l'espace de travail cible pour l'analyse post-mortem.
  • Associez toujours les vérificateurs de compilation et d'exécution dans le cloud (dataform_cloud_compile, dataform_cloud_run) à des rubriques binaires basées sur des LLM pour identifier à la fois les erreurs de syntaxe ou d'exécution et les défauts de logique de haut niveau.
  • Activez les rapports BigQuery (<PROJECT_ID>.evalbench.results) et utilisez les liens Data Studio générés pour suivre les taux de réussite, la précision de l'utilisation des outils et l'efficacité des requêtes au fil du temps.