Limitations connues de l'API Conversational Analytics

L'API Conversational Analytics présente les limites connues suivantes concernant le nombre de sources de données, le style des visualisations et la taille des ensembles de données.

Limites des sources de données

Cette section décrit les contraintes et les comportements de l'API Conversational Analytics lorsque vous vous connectez à des sources Looker et de base de données (AlloyDB pour PostgreSQL, Cloud SQL pour MySQL, Cloud SQL pour PostgreSQL et Spanner) et que vous les interrogez.

Limites des sources de données Looker

Lorsque vous vous connectez à une source de données Looker, tenez compte des points suivants :

  • Vous pouvez interroger n'importe quelle exploration incluse dans une conversation.
  • Un agent ne peut interroger qu'une seule exploration à la fois. Il n'est pas possible d'effectuer des requêtes dans plusieurs Explorations simultanément.
  • Un agent peut interroger plusieurs explorations dans la même conversation.

  • Un agent peut interroger plusieurs explorations dans une conversation qui inclut des questions en plusieurs parties ou des questions de suivi.

    Par exemple, un utilisateur connecte deux explorations, l'une appelée cat-explore et l'autre dog-explore. Il saisit la question "Qu'est-ce qui est le plus grand : le nombre de chats ou le nombre de chiens ?". Deux requêtes sont alors créées : une pour compter le nombre de chats dans cat-explore et une autre pour compter le nombre de chiens dans dog-explore. L'agent compare le nombre obtenu à partir des deux requêtes après les avoir exécutées.

  • La méthode QueryData n'est pas compatible avec les sources de données BigQuery ni Looker.

Limites des sources de données de base de données

Lorsque vous vous connectez à des sources de données AlloyDB, Cloud SQL pour MySQL, Cloud SQL pour PostgreSQL ou Spanner, tenez compte des points suivants :

  • Les agents de données accèdent aux données à l'aide des identifiants de l'utilisateur qui interagit avec l'agent de données. Si un utilisateur accède à un agent de données partagé pour lequel il n'a pas accès aux tables configurées de l'agent, l'agent de données ne peut pas accéder à ces tables.

  • La sélection de tables pour l'agent de données indique à votre agent sur quelles tables se concentrer. La sélection de tables n'est pas un paramètre de sécurité. Même si vous spécifiez que la source de données ne peut extraire des informations que de certaines tables (comme table1 et table2), le système peut toujours renvoyer des données d'une table non prévue (table3) si l'utilisateur qui exécute la requête dispose d'autorisations générales pour afficher le contenu de table3 dans la même base de données.

Limites de visualisation

Les types de visualisations suivants sont acceptés :

  • Zone
  • Bar
  • Forme géographique
  • Carte de densité
  • Courbe (série temporelle)
  • Secteurs
  • Nuage de points

Limites de traitement des données

  • Pour les sources de données Looker, l'API Conversational Analytics peut renvoyer jusqu'à 5 000 lignes par requête.
  • Pour les sources de données BigQuery, l'API Conversational Analytics limite les requêtes de données à 500 Go de données traitées.
  • Pour les sources de données AlloyDB, Cloud SQL pour MySQL, Cloud SQL pour PostgreSQL et Spanner, l'API Conversational Analytics peut renvoyer jusqu'à 1 000 lignes par requête.
  • Les fonctionnalités de raisonnement et de récupération de contenu basées sur Python de l'API Conversational Analytics peuvent gérer des complexités temporelles allant jusqu'à O(100k) lignes.
  • L'interrogation de grandes quantités de données peut entraîner une réduction de la précision du raisonnement dans les agents de données.
  • La longueur maximale de jetons de sortie de l'API Conversational Analytics est de 8 192 jetons. L'interrogation de grandes quantités de données peut renvoyer une erreur MAX_TOKENS.
  • Les données renvoyées dans le champ DataResult d'un message système sont soumises à une limite de taille. Les résultats de données sont tronqués à un maximum de 3 000 000 octets. Ce processus de troncature conserve autant de lignes complètes que possible dans cette limite de taille.

Limites des requêtes

  • La fonctionnalité de noms de colonnes flexibles de BigQuery n'est pas prise en charge.
  • Les structs dans BigQuery sont pris en charge, mais peuvent parfois échouer.
  • Pour les sources de données Looker, l'API ne peut pas définir la valeur d'un champ réservé au filtrage défini à l'aide du paramètre LookML parameter.
  • L'utilisation de l'API Conversational Analytics pour se connecter à une instance Looker (Google Cloud Core) avec adresse IP privée à l'aide de Data Studio Pro lorsque cette instance Looker (Google Cloud Core) se trouve dans un périmètre VPC Service Controls n'est pas une configuration compatible et ne répond pas aux exigences de conformité de VPC Service Controls.
  • Pour les connexions aux instances Looker (Google Cloud Core) avec des configurations d'adresse IP privée, l'API Conversational Analytics n'est pas compatible avec les instances Looker (Google Cloud Core) configurées pour utiliser une CMEK ou VPC Service Controls.
  • Pour les ressources de l'API Conversational Analytics, CMEK n'est compatible qu'avec les sources de données Looker.
  • L'API Conversational Analytics ne fonctionne pas bien avec les sources de données Data Studio pour lesquelles l'option Modification des champs dans les rapports est désactivée, car ce paramètre empêche Conversational Analytics de créer des champs calculés.

  • En cas d'échec lors de la validation ou de l'exécution d'une requête, l'API Conversation Analytics peut réessayer automatiquement l'opération en générant une requête corrigée. Ce type de nouvelle tentative sera effectué trois fois maximum par requête.

    Si une requête échoue en raison de problèmes d'autorisation ou d'authentification, l'API Conversational Analytics ne la relancera pas. Les nouvelles tentatives ne sont pas déterministes. Si le message d'erreur suggère qu'une requête est irrécupérable, l'API ne la réessaiera pas, même si elle est toujours en dessous de la limite de trois erreurs par requête.

Limitations de quota

  • L'API Conversational Analytics présente les limites suivantes pour les requêtes globales (y compris les requêtes de chat et les autres) :
    • Un taux maximal de 10 requêtes par seconde (RPS), soit 600 requêtes par minute (RPM) par projet.
    • Un taux maximal de 10 RPS, soit 600 RPM par utilisateur et par projet.
  • Par exception, les demandes de chat sont soumises à des limites plus strictes :
    • Un taux maximal de 30 requêtes par minute et par projet.
    • Un taux maximal de 30 QPM par utilisateur et par projet.
  • L'API Conversational Analytics pour AlloyDB, Cloud SQL pour MySQL, Cloud SQL pour PostgreSQL et Spanner est limitée à 50 requêtes par minute et par projet. Pour augmenter ces limites, contactez l'assistanceGoogle Cloud .

Limites concernant les types de questions

  • L'API Conversational Analytics accepte les questions auxquelles il est possible de répondre à l'aide d'une seule visualisation. Voici quelques exemples :

    • Tendances des métriques au fil du temps
    • Ventilation ou répartition d'une métrique par dimension
    • Valeurs uniques pour une ou plusieurs dimensions
    • Valeurs de métriques uniques
    • Valeurs de dimension les plus élevées par métrique

  • L'API Conversational Analytics n'accepte pas encore les questions auxquelles il n'est possible de répondre qu'avec les types de visualisations complexes suivants :

    • Prédiction et prévision
    • Analyse statistique avancée, y compris corrélation et détection des anomalies