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 sur 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.

    Exemple : Un utilisateur connecte deux explorations, l'une appelée cat-explore et l'autre dog-explore. L'utilisateur saisit la question "Qu'est-ce qui est le plus élevé : le nombre de chats ou le nombre de chiens ?". Cela crée deux requêtes : 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 les nombres des deux requêtes une fois qu'elles sont terminé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 la table pour l'agent de données indique à votre agent sur quelles tables se concentrer. La sélection de la table 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 relatives au 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 traités.
  • 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 sortie de jeton 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 des 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 contrainte 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) disposant d'une 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, les CMEK ne sont compatibles 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é au maximum trois fois par requête.

    Si une requête échoue en raison de problèmes d'autorisation ou d'authentification, l'API Conversational Analytics ne la réessayera 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éessayera pas, même si elle est toujours inférieure à la limite de trois erreurs par requête.

Limites de quota

  • L'API Conversational Analytics présente les limites suivantes pour les requêtes globales (y compris les requêtes de chat et non liées au chat) :
    • Une fréquence maximale de 10 requêtes par seconde (RPS), soit 600 requêtes par minute (RPM) par projet.
    • Une fréquence maximale de 10 RPS, soit 600 RPM par utilisateur et par projet.
  • Exceptionnellement, les requêtes de chat sont soumises à des limites plus restrictives :
    • Une fréquence maximale de 30 RPM par projet.
    • Une fréquence maximale de 30 RPM 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 RPM par projet. Pour augmenter ces limites, contactez Google Cloud le service client.

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